From 901bebdc14f00f7fffdd61ca4a61698dfed69f86 Mon Sep 17 00:00:00 2001 From: EuAndreh Date: Sat, 14 Nov 2020 15:44:04 -0300 Subject: Spell check, add translation files and publish article on local-first software --- ...ur-data-in-spite-of-the-cloud-article-review.md | 303 ------------- ...ur-data-in-spite-of-the-cloud-article-review.md | 306 +++++++++++++ ...ocal-first-beyond-the-crdt-silver-bullet.slides | 272 ----------- ...ocal-first-beyond-the-crdt-silver-bullet.slides | 270 +++++++++++ ...ur-data-in-spite-of-the-cloud-article-review.po | 497 +++++++++++++++++++++ ...l-first-beyond-the-crdt-silver-bullet.slides.po | 322 +++++++++++++ ...ur-data-in-spite-of-the-cloud-article-review.po | 497 +++++++++++++++++++++ ...l-first-beyond-the-crdt-silver-bullet.slides.po | 322 +++++++++++++ ...ur-data-in-spite-of-the-cloud-article-review.po | 497 +++++++++++++++++++++ ...l-first-beyond-the-crdt-silver-bullet.slides.po | 322 +++++++++++++ scripts/spelling/en.txt | 2 + scripts/spelling/international.txt | 19 + 12 files changed, 3054 insertions(+), 575 deletions(-) delete mode 100644 _articles/2020-10-26-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md create mode 100644 _articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md delete mode 100644 _slides/2020-10-26-on-local-first-beyond-the-crdt-silver-bullet.slides create mode 100644 _slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides create mode 100644 locale/eo/LC_MESSAGES/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.po create mode 100644 locale/eo/LC_MESSAGES/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides.po create mode 100644 locale/fr/LC_MESSAGES/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.po create mode 100644 locale/fr/LC_MESSAGES/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides.po create mode 100644 locale/pt/LC_MESSAGES/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.po create mode 100644 locale/pt/LC_MESSAGES/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides.po diff --git a/_articles/2020-10-26-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md b/_articles/2020-10-26-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md deleted file mode 100644 index 409dfaf..0000000 --- a/_articles/2020-10-26-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md +++ /dev/null @@ -1,303 +0,0 @@ ---- - -title: "Local-First Software: You Own Your Data, in spite of the Cloud - article review" - -date: 2020-11-14 - -layout: post - -lang: en - -ref: local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review - -eu_categories: presentation,article review - -published: false - ---- - -*This article is derived from a [presentation][presentation] given at a Papers -We Love meetup on the same subject.* - -This is a review of the article -"[Local-First Software: You Own Your Data, in spite of the Cloud][article-pdf]", -by M. Kleppmann, A. Wiggins, P. Van Hardenberg and M. F. McGranaghan. - -### Offline-first, local-first - -The "local-first" term they use isn't new, and I have used it myself in the past -to refer to this types of application, where the data lives primarily on the -client, and there are conflict resolution algorithms that reconcile data created -on different instances. - -Sometimes I see confusion with this idea and "client-side", "offline-friendly", -"syncable", etc. I have myself used this terms, also. - -There exists, however, already the "offline-first" term, which conveys almost -all of that meaning. In my view, "local-first" doesn't extend "offline-first" in -any aspect, rather it gives a well-defined meaning to it instead. I could say -that "local-first" is just "offline-first", but with 7 well-defined ideals -instead of community best practices. - -It is a step forward, and given the number of times I've seen the paper shared -around I think there's a chance people will prefer saying "local-first" in lieu -of "offline-first" from now on. - -[presentation]: {% link _slides/2020-10-26-on-local-first-beyond-the-crdt-silver-bullet.slides %} -[article-pdf]: https://martin.kleppmann.com/papers/local-first.pdf - -### Software licenses - -On a footnote of the 7th ideal ("You Retain Ultimate Ownership and Control"), -the authors say: - -> In our opinion, maintaining control and ownership of data does not mean that -> the software must necessarily be open source. (...) as long as it does not -> artificially restrict what users can do with their files. - -They give examples of artificial restrictions, like this one: - -```bash -#!/bin/sh - -TODAY=$(date +%s) -LICENSE_EXPIRATION=$(date -d 2020-11-15 +%s) - -if [ $TODAY -ge $LICENSE_EXPIRATION ]; then - echo 'License expired!' - exit 1 -fi - -echo $((2 + 2)) -``` - -Now when using this very useful program: - -```bash -# today -$ ./useful-adder.sh -4 -# tomorrow -$ ./useful-adder.sh -License expired! -``` - -This is obviously an intentional restriction, and it goes against the 5th ideal -("The Long Now"). This software would only be useful as long as the embedded -license expiration allowed. Sure you could change the clock on the computer, but -there are many other ways that this type of intentional restriction is in -conflict with that ideal. - -However, what about unintentional restrictions? What if a software had an equal -or similar restriction, and stopped working after days pass? Or what if the -programmer added a constant to make the development simpler, and this led to -unintentionally restricting the user? - -```bash -# today -$ useful-program -# ...useful output... - -# tomorrow, with more data -$ useful-program -ERROR: Panic! Stack overflow! -``` - -Just as easily as I can come up with ways to intentionally restrict users, just -as easily I can do the same for unintentionally restricting users. A program can -stop working for a variety of reasons. - -If it stops working due do data growth, what are the options? Reverting to an -earlier backup, and making it read-only? That isn't really a "Long Now", but -rather a "Long Now as long as the software keeps working as expected". - -The point is: if the software isn't free/libre, "The Long Now" isn't achievable -without a lot of wishful thinking. Maybe the authors were trying to be more -friendly towards business who don't like FOSS, but in doing so they've proposed -a contradiction by reconciling "The Long Now" with proprietary software. - -It isn't the same as saying that any free/libre software achieves that ideal, -either. The license can still be free, but the source code can become -unavailable due to cloud rot. Or maybe the build is undocumented, or the build -tools had specific configuration that one has to guess. A piece of free/libre -software can still fail to achieve "The Long Now". Being free doesn't guarantee -it, just makes it possible. - -A colleague has challenged my view, arguing that the software doesn't really -need to be free, as long as there is an specification of the file format. This -way is the software stops working, the format can still be processed by other -programs. But this doesn't apply in practice: if you have a document that you -write to, and software stops working, you still want to write to the document. -An external tool that navigates the content and shows it to you won't allow you -to keep writing, and when it does that tool is now starting to reimplement the -software. - -An open specification could serve as a blueprint to other implementations, -making the data format more friendly to reverse-engineering. But the -reimplementation still has to exist, at which point the original software failed -to achieve "The Long Now". - -It is less bad, but still not quite there yet. - -### Denial of existing solutions - -When describing "Existing Data Storage and Sharing Models", on a -footnote[^devil] the authors say: - -[^devil]: This is the second aspect that I'm picking on the article from a - footnote. I guess the devil really is on the details. - -> In principle it is possible to collaborate without a repository service, -> e.g. by sending patch files by email, but the majority of Git users rely -> on GitHub. - -The authors go to a great length to talk about usability of cloud apps, and even -point to research they've done on it, but they've missed learning more from -local-first solutions that already exist. - -Say the automerge CRDT proves to be even more useful than what everybody -imagined. Say someone builds a local-first repository service using it. How will -it change anything of the Git/GitHub model? What is different about it that -prevents people in the future writing a paper saying: - -> In principle it is possible to collaborate without a repository service, -> e.g. by using automerge and platform X, -> but the majority of Git users rely on GitHub. - -How is this any better? - -If it is already [possible][git-local-first] to have a local-first development -workflow, why don't people use it? Is it just fashion, or there's a fundamental -problem with it? If so, what is it, and how to avoid it? - -If sending patches by emails is perfectly possible but out of fashion, why even -talk about Git/GitHub? Isn't this a problem that people are putting themselves -in? How can CDRTs possibly prevent people from doing that? - -My impression is that the authors envision a better future, where development is -fully decentralized unlike today, and somehow CDRTs will make that happen. If -more people think this way, "CRDT" is next in line to the buzzword list that -solves everything, like "containers", "blockchain" or "machine learning". - -Rather than picturing an imaginary service that could be described like -"GitHub+CRDTs" and people would adopt it, I'd rather better understand why -people don't do it already, since Git is built to work like that. - -[git-local-first]: https://drewdevault.com/2018/07/23/Git-is-already-distributed.html - -### Ditching of web applications - -The authors put web application in a worse position for building local-first -application, claiming that: - -> (...) the architecture of web apps remains fundamentally server-centric. -> Offline support is an afterthought in most web apps, and the result is -> accordingly fragile. - -Well, I disagree. - -The problem isn't inherit to the web platform, but instead how people use it. - -I have myself built offline-first applications, leveraging IndexedDB, App Cache, -*etc*. I wanted to build an offline-first application on the web, and so I did. - -In fact, many people choose [PouchDB][pouchdb] *because* of that, since it is a -good tool for offline-first web applications. The problem isn't really the -technology, but how much people want their application to be local-first. - -Constrast it with Android [Instant Apps][instant-apps], where applications are -sent to the phone in small parts. Since this requires an internet connection to -move from a part of the app bundle to another, a subset of the app isn't -local-first, despite being an app. - -The point isn't the technology, but how people are using it. Local-first web -applications are perfectly possible, just like non-local-first native -applications are possible. - -[pouchdb]: https://pouchdb.com/ -[instant-apps]: https://developer.android.com/topic/google-play-instant - -### Costs are underrated - -I think the costs of "old-fashined apps" over "cloud apps" are underrated, -mainly regarding storage, and that this costs can vary a lot by application. - -Say a person writes online articles for their personal website, and puts -everything into Git. Since there isn't supposed to be any collaboration, all -of the relevant ideals of local-first are achieved. - -Now another person creates videos instead of articles. They could try keeping -everything local, but after some time the storage usage fills the entire disk. -This person's local-first setup would be much more complex, and would cost much -more on maintenence, backup and storage. - -Even though both have similar needs, a local-first video repository is much more -demanding. So the local-first thinking here isn't "just keep everything local", -but "how much time and money am I willing to spend to keep everything local". - -The convenience of "cloud apps" becomes so attractive that many don't even have -a local copy of their videos, and rely exclusively on service providers to -maintain, backup and store their content. - -The dial measuring "cloud apps" and "old-fashined apps" needs to be specific to -use-cases. - -### Real-time collaboration is optional - -If I were the one making the list of ideals, I wouldn't focus so much on -real-time collaboration. - -Even though seamless collaboration is desired, it being real-time depends on the -network being available for that. But ideal 3 states that -"The Network is Optional", so real-time collaboration is also optional. - -The fundamentals of a local-first system should enable real-time collaboration -when network is available, but shouldn't focus on it. - -On many places when discussing applications being offline, it is common for me -to find people saying that their application works -"even on a plane, subway or elevator". That is a reflection of when said -developers have to deal with networks being unavailable. - -But this leaves out a big chunck of the world where internet connection is -intermittent, or only work every other day or only once a week, or stops -working when it rains, *etc*. For this audience, living without network -connectivity isn't such a discrete moment in time, but part of every day life. I -like the fact that the authors acknowledge that. - -When discussing "working offline", I'd rather keep this type of person in mind, -then the subset of people who are offline when on the elevator will naturally be -included. - -### On CRDTs and developer experience - -When discussing developer experience, the authors bring up some questions to be -answered further, like: - -> For an app developer, how does the use of a CRDT-based data layer compare to -> existing storage layers like a SQL database, a filesystem, or CoreData? Is a -> distributed system harder to write software for? - -That is an easy one: yes. - -A distributed system *is* harder to write software for, being a distributed -system. - -Adding a large layer of data structures and algorithms will make it more complex -to write software for, naturally. And if trying to make this layer transparent -to the programmer, so they can pretend that layer doesn't exist is a bad idea, -as RPC frameworks have tried, and failed. See -"[A Note on Distributed Computing][note-dist-comp]" for a critique on RPC -frameworks trying to make the network invisible, which I think also applies in -equivalence for making the CRDTs layer invisible. - -[rmi-wiki]: https://en.wikipedia.org/wiki/Java_remote_method_invocation -[note-dist-comp]: https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf - -## Conclusion - -I liked a lot the article, as it took the "offline-first" philosophy and ran -with it. - -But I think the authors' view of adding CRDTs and things becoming local-first is -a bit too magical. diff --git a/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md b/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md new file mode 100644 index 0000000..1a41c0c --- /dev/null +++ b/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md @@ -0,0 +1,306 @@ +--- + +title: "Local-First Software: You Own Your Data, in spite of the Cloud - article review" + +date: 2020-11-14 + +layout: post + +lang: en + +ref: local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review + +eu_categories: presentation,article review + +--- + +*This article is derived from a [presentation][presentation] given at a Papers +We Love meetup on the same subject.* + +This is a review of the article +"[Local-First Software: You Own Your Data, in spite of the Cloud][article-pdf]", +by M. Kleppmann, A. Wiggins, P. Van Hardenberg and M. F. McGranaghan. + +### Offline-first, local-first + +The "local-first" term they use isn't new, and I have used it myself in the past +to refer to this types of application, where the data lives primarily on the +client, and there are conflict resolution algorithms that reconcile data created +on different instances. + +Sometimes I see confusion with this idea and "client-side", "offline-friendly", +"syncable", etc. I have myself used this terms, also. + +There exists, however, already the "offline-first" term, which conveys almost +all of that meaning. In my view, "local-first" doesn't extend "offline-first" in +any aspect, rather it gives a well-defined meaning to it instead. I could say +that "local-first" is just "offline-first", but with 7 well-defined ideals +instead of community best practices. + +It is a step forward, and given the number of times I've seen the paper shared +around I think there's a chance people will prefer saying "local-first" in +*lieu* of "offline-first" from now on. + +[presentation]: {% link _slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides %} +[article-pdf]: https://martin.kleppmann.com/papers/local-first.pdf + +### Software licenses + +On a footnote of the 7th ideal ("You Retain Ultimate Ownership and Control"), +the authors say: + +> In our opinion, maintaining control and ownership of data does not mean that +> the software must necessarily be open source. (...) as long as it does not +> artificially restrict what users can do with their files. + +They give examples of artificial restrictions, like this artificial restriction +I've come up with: + +```bash +#!/bin/sh + +TODAY=$(date +%s) +LICENSE_EXPIRATION=$(date -d 2020-11-15 +%s) + +if [ $TODAY -ge $LICENSE_EXPIRATION ]; then + echo 'License expired!' + exit 1 +fi + +echo $((2 + 2)) +``` + +Now when using this very useful program: + +```bash +# today +$ ./useful-adder.sh +4 +# tomorrow +$ ./useful-adder.sh +License expired! +``` + +This is obviously an intentional restriction, and it goes against the 5th ideal +("The Long Now"). This software would only be useful as long as the embedded +license expiration allowed. Sure you could change the clock on the computer, but +there are many other ways that this type of intentional restriction is in +conflict with that ideal. + +However, what about unintentional restrictions? What if a software had an equal +or similar restriction, and stopped working after days pass? Or what if the +programmer added a constant to make the development simpler, and this led to +unintentionally restricting the user? + +```bash +# today +$ useful-program +# ...useful output... + +# tomorrow, with more data +$ useful-program +ERROR: Panic! Stack overflow! +``` + +Just as easily as I can come up with ways to intentionally restrict users, I can +do the same for unintentionally restrictions. A program can stop working for a +variety of reasons. + +If it stops working due do, say, data growth, what are the options? Reverting to +an earlier backup, and making it read-only? That isn't really a "Long Now", but +rather a "Long Now as long as the software keeps working as expected". + +The point is: if the software isn't free/libre, "The Long Now" isn't achievable +without a lot of wishful thinking. Maybe the authors were trying to be more +friendly towards business who don't like FOSS, but in doing so they've proposed +a contradiction by reconciling "The Long Now" with proprietary software. + +It isn't the same as saying that any free/libre software achieves that ideal, +either. The license can still be free, but the source code can become +unavailable due to cloud rot. Or maybe the build is undocumented, or the build +tools had specific configuration that one has to guess. A piece of free/libre +software can still fail to achieve "The Long Now". Being free doesn't guarantee +it, just makes it possible. + +A colleague has challenged my view, arguing that the software doesn't really +need to be free, as long as there is an specification of the file format. This +way if the software stops working, the format can still be processed by other +programs. But this doesn't apply in practice: if you have a document that you +write to, and software stops working, you still want to write to the document. +An external tool that navigates the content and shows it to you won't allow you +to keep writing, and when it does that tool is now starting to re-implement the +software. + +An open specification could serve as a blueprint to other implementations, +making the data format more friendly to reverse-engineering. But the +re-implementation still has to exist, at which point the original software failed +to achieve "The Long Now". + +It is less bad, but still not quite there yet. + +### Denial of existing solutions + +When describing "Existing Data Storage and Sharing Models", on a +footnote[^devil] the authors say: + +[^devil]: This is the second aspect that I'm picking on the article from a + footnote. I guess the devil really is on the details. + +> In principle it is possible to collaborate without a repository service, +> e.g. by sending patch files by email, but the majority of Git users rely +> on GitHub. + +The authors go to a great length to talk about usability of cloud apps, and even +point to research they've done on it, but they've missed learning more from +local-first solutions that already exist. + +Say the automerge CRDT proves to be even more useful than what everybody +imagined. Say someone builds a local-first repository service using it. How will +it change anything of the Git/GitHub model? What is different about it that +prevents people in the future writing a paper saying: + +> In principle it is possible to collaborate without a repository service, +> e.g. by using automerge and platform X, +> but the majority of Git users rely on GitHub. + +How is this any better? + +If it is already [possible][git-local-first] to have a local-first development +workflow, why don't people use it? Is it just fashion, or there's a fundamental +problem with it? If so, what is it, and how to avoid it? + +If sending patches by emails is perfectly possible but out of fashion, why even +talk about Git/GitHub? Isn't this a problem that people are putting themselves +in? How can CRDTs possibly prevent people from doing that? + +My impression is that the authors envision a better future, where development is +fully decentralized unlike today, and somehow CRDTs will make that happen. If +more people think this way, "CRDT" is next in line to the buzzword list that +solves everything, like "containers", "blockchain" or "machine learning". + +Rather than picturing an imaginary service that could be described like +"GitHub+CRDTs" and people would adopt it, I'd rather better understand why +people don't do it already, since Git is built to work like that. + +[git-local-first]: https://drewdevault.com/2018/07/23/Git-is-already-distributed.html + +### Ditching of web applications + +The authors put web application in a worse position for building local-first +application, claiming that: + +> (...) the architecture of web apps remains fundamentally server-centric. +> Offline support is an afterthought in most web apps, and the result is +> accordingly fragile. + +Well, I disagree. + +The problem isn't inherit to the web platform, but instead how people use it. + +I have myself built offline-first applications, leveraging IndexedDB, App Cache, +*etc*. I wanted to build an offline-first application on the web, and so I did. + +In fact, many people choose [PouchDB][pouchdb] *because* of that, since it is a +good tool for offline-first web applications. The problem isn't really the +technology, but how much people want their application to be local-first. + +Contrast it with Android [Instant Apps][instant-apps], where applications are +sent to the phone in small parts. Since this requires an internet connection to +move from a part of the app bundle to another, a subset of the app isn't +local-first, despite being an app. + +The point isn't the technology, but how people are using it. Local-first web +applications are perfectly possible, just like non-local-first native +applications are possible. + +[pouchdb]: https://pouchdb.com/ +[instant-apps]: https://developer.android.com/topic/google-play-instant + +### Costs are underrated + +I think the costs of "old-fashioned apps" over "cloud apps" are underrated, +mainly regarding storage, and that this costs can vary a lot by application. + +Say a person writes online articles for their personal website, and puts +everything into Git. Since there isn't supposed to be any collaboration, all +of the relevant ideals of local-first are achieved. + +Now another person creates videos instead of articles. They could try keeping +everything local, but after some time the storage usage fills the entire disk. +This person's local-first setup would be much more complex, and would cost much +more on maintenance, backup and storage. + +Even though both have similar needs, a local-first video repository is much more +demanding. So the local-first thinking here isn't "just keep everything local", +but "how much time and money am I willing to spend to keep everything local". + +The convenience of "cloud apps" becomes so attractive that many don't even have +a local copy of their videos, and rely exclusively on service providers to +maintain, backup and store their content. + +The dial measuring "cloud apps" and "old-fashioned apps" needs to be specific to +use-cases. + +### Real-time collaboration is optional + +If I were the one making the list of ideals, I wouldn't focus so much on +real-time collaboration. + +Even though seamless collaboration is desired, it being real-time depends on the +network being available for that. But ideal 3 states that +"The Network is Optional", so real-time collaboration is also optional. + +The fundamentals of a local-first system should enable real-time collaboration +when network is available, but shouldn't focus on it. + +On many places when discussing applications being offline, it is common for me +to find people saying that their application works +"even on a plane, subway or elevator". That is a reflection of when said +developers have to deal with networks being unavailable. + +But this leaves out a big chunk of the world where internet connection is +intermittent, or only works every other day or only once a week, or stops +working when it rains, *etc*. For this audience, living without network +connectivity isn't such a discrete moment in time, but part of every day life. I +like the fact that the authors acknowledge that. + +When discussing "working offline", I'd rather keep this type of person in mind, +then the subset of people who are offline when on the elevator will naturally be +included. + +### On CRDTs and developer experience + +When discussing developer experience, the authors bring up some questions to be +answered further, like: + +> For an app developer, how does the use of a CRDT-based data layer compare to +> existing storage layers like a SQL database, a filesystem, or CoreData? Is a +> distributed system harder to write software for? + +That is an easy one: yes. + +A distributed system *is* harder to write software for, being a distributed +system. + +Adding a large layer of data structures and algorithms will make it more complex +to write software for, naturally. And if trying to make this layer transparent +to the programmer, so they can pretend that layer doesn't exist is a bad idea, +as RPC frameworks have tried, and failed. + +See "[A Note on Distributed Computing][note-dist-comp]" for a critique on RPC +frameworks trying to make the network invisible, which I think also applies in +equivalence for making the CRDTs layer invisible. + +[rmi-wiki]: https://en.wikipedia.org/wiki/Java_remote_method_invocation +[note-dist-comp]: https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf + +## Conclusion + +I liked a lot the article, as it took the "offline-first" philosophy and ran +with it. + +But I think the authors' view of adding CRDTs and things becoming local-first is +a bit too magical. + +This particular area is one that I have large interest on, and I wish to see +more being done on the "local-first" space. diff --git a/_slides/2020-10-26-on-local-first-beyond-the-crdt-silver-bullet.slides b/_slides/2020-10-26-on-local-first-beyond-the-crdt-silver-bullet.slides deleted file mode 100644 index 02f6cc7..0000000 --- a/_slides/2020-10-26-on-local-first-beyond-the-crdt-silver-bullet.slides +++ /dev/null @@ -1,272 +0,0 @@ ---- - -title: 'On "local-first": beyond the CRDT silver bullet' - -date: 2020-10-26 - -layout: slides - -lang: en - -ref: on-local-first-beyond-the-crdt-silver-bullet - -published: false - ---- - -# On local-first - -Beyond the CRDT silver bullet - ---- - -# Part 1 - -Exposition - ---- - -## "cloud apps" vs "old-fashined apps" - ---- - -## Target - -- documents -- files -- personal data repositories - -Not: banking services, e-commerce, social networking, ride-sharing, *etc*. - ---- - -## 7 Ideals for local-first software - ---- - -### 1 - No Spinners: Your Work at Your Fingertips - ---- - -### 2 - Your Work Is Not Trapped on One Device - ---- - -### 3 - The Network Is Optional - ---- - -### 4 - Seamless Collaboration with Your Colleagues - ---- - -### 5 - The Long Now - ---- - -### 6 - Security and Privacy by Default - ---- - -### 7 - You Retain Ultimate Ownership and Control - ---- - -## Towards a Better Future - -CRDTs (Conflict-free Replicated Data Types) as a Foundational Technology - ---- - -### Use case - -``` -# in node A and node B -s = "Hello, World" - -# in node A -s = "Hello, Alice" - -# in node B -s = "Hello, Bob" -``` - -How to reconcile those? -- `Hello, ABloibce` -- `Hello, AliceBob` -- `Hello, BobAlice` -- `Hello, Alice` -- `Hello, Bob` - ---- - -Existing CRDTs differ: -- performance -- storage -- compression -- metadata overhead - ---- - -Hint towards the "automerge" CRDT - ---- - -*show comparison table, page 9* - ---- - -# Part 2 - -Critique - ---- - -### Software license - -> In our opinion, maintaining control and ownership of data does not mean that -> the software must necessarily be open source. - ---- - -#### Example 1 - intentional restriction - -```bash -#!/bin/sh - -TODAY=$(date +%s) -LICENSE_EXPIRATION=$(date -d 2020-10-27 +%s) - -if [ $TODAY -ge $LICENSE_EXPIRATION ]; then - echo 'License expired!' - exit 1 -fi - -echo $((2 + 2)) -``` - -```bash -# today -$ ./useful-adder.sh -4 -# tomorrow -$ ./useful-adder.sh -License expired! -``` - ---- - -#### Example 2 - unintentional restriction - -```bash -# today -$ useful-program -# ...useful output... - -# tomorrow, with more data -$ useful-program -ERROR: Panic! Stack overflow! -``` ---- - -### local-first **requires** free/libre software - -Otherwise "The Long Now" (ideal nº5) is lost - ---- - -### Denial of existing solutions - -> In principle it is possible to collaborate without a repository service, -> e.g. by sending patch files by email, but the majority of Git users rely -> on GitHub. - -Solution: either GitHub+CRDTs or `git` **`send-email`** - ---- - -### Plain text formats - -> Git is highly optimized for code and similar line-based text file - -It even pulls software to the plain text direction, e.g.: -- delivery-templates -- `common-core.protocols.config` - -Why not exploit that more? - ---- - -### Ditching of web applications - -> The architecture of web apps remains fundamentally server-centric - -Disagree. Constrast [PouchDB][pouchdb] with Android [Instant Apps][instant-apps] - -[pouchdb]: https://pouchdb.com/ -[instant-apps]: https://developer.android.com/topic/google-play-instant - -??? - -Talk on dynamic content - ---- - -### Costs are underrated - -- storage -- backups -- maintanence - -Example: blog vs vlog - ---- - -### Real-time collaboration a bit overrated - -It is only possible on the presence of reliable, medium-quality network -connection - -> X also works when inside an elevator, subway or plane! - - - ---- - -### On CRDTs and developer experience - -> For an app developer, how does the use of a CRDT-based data layer compare to -> existing storage layers like a SQL database, a filesystem, or CoreData? Is a -> distributed system harder to write software for? - -Yes. - -See "[A Note on Distributed Computing][note-dist-comp]" - -[note-dist-comp]: https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf - ---- - -## Conclusion - -Why this is a "paper I love": it took offline-first and ran with it. - -But a pinch of CRDT won't make the world local-first. - -The tricky part is the end of the sentence: "**in spite of the Cloud**". - ---- - -## Thank you! - -References: - -1. these slides: [{{ site.tld }}/slides.html]({% link slides.md %}) -2. [prose version of this presentation]({% link _articles/2020-10-26-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md %}) -3. "[Local-First Software: You Own Your Data, in spite of the Cloud](https://martin.kleppmann.com/papers/local-first.pdf)", - by M. Kleppmann, A. Wiggins, P. Van Hardenberg and M. F. McGranaghan -4. [The Morning Paper](https://blog.acolyer.org/2019/11/20/local-first-software/) - article -5. "[A Note on Distributed Computing][note-dist-comp]", by J. Waldo, G. Wyant, A. Wollrath and S Kendall - -[note-dist-comp]: https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf diff --git a/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides b/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides new file mode 100644 index 0000000..425648f --- /dev/null +++ b/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides @@ -0,0 +1,270 @@ +--- + +title: 'On "local-first": beyond the CRDT silver bullet' + +date: 2020-11-14 + +layout: slides + +lang: en + +ref: on-local-first-beyond-the-crdt-silver-bullet + +--- + +# On local-first + +Beyond the CRDT silver bullet + +--- + +# Part 1 + +Exposition + +--- + +## "cloud apps" vs "old-fashioned apps" + +--- + +## Target + +- documents +- files +- personal data repositories + +Not: banking services, e-commerce, social networking, ride-sharing, *etc*. + +--- + +## 7 Ideals for local-first software + +--- + +### 1 - No Spinners: Your Work at Your Fingertips + +--- + +### 2 - Your Work Is Not Trapped on One Device + +--- + +### 3 - The Network Is Optional + +--- + +### 4 - Seamless Collaboration with Your Colleagues + +--- + +### 5 - The Long Now + +--- + +### 6 - Security and Privacy by Default + +--- + +### 7 - You Retain Ultimate Ownership and Control + +--- + +## Towards a Better Future + +CRDTs (Conflict-free Replicated Data Types) as a Foundational Technology + +--- + +### Use case + +``` +# in node A and node B +s = "Hello, World" + +# in node A +s = "Hello, Alice" + +# in node B +s = "Hello, Bob" +``` + +How to reconcile those? +- `Hello, ABloibce` +- `Hello, AliceBob` +- `Hello, BobAlice` +- `Hello, Alice` +- `Hello, Bob` + +--- + +Existing CRDTs differ: +- performance +- storage +- compression +- metadata overhead + +--- + +Hint towards the "automerge" CRDT + +--- + +*show comparison table, page 9* + +--- + +# Part 2 + +Critique + +--- + +### Software license + +> In our opinion, maintaining control and ownership of data does not mean that +> the software must necessarily be open source. + +--- + +#### Example 1 - intentional restriction + +```bash +#!/bin/sh + +TODAY=$(date +%s) +LICENSE_EXPIRATION=$(date -d 2020-10-27 +%s) + +if [ $TODAY -ge $LICENSE_EXPIRATION ]; then + echo 'License expired!' + exit 1 +fi + +echo $((2 + 2)) +``` + +```bash +# today +$ ./useful-adder.sh +4 +# tomorrow +$ ./useful-adder.sh +License expired! +``` + +--- + +#### Example 2 - unintentional restriction + +```bash +# today +$ useful-program +# ...useful output... + +# tomorrow, with more data +$ useful-program +ERROR: Panic! Stack overflow! +``` +--- + +### local-first **requires** free/libre software + +Otherwise "The Long Now" (ideal nº5) is lost + +--- + +### Denial of existing solutions + +> In principle it is possible to collaborate without a repository service, +> e.g. by sending patch files by email, but the majority of Git users rely +> on GitHub. + +Solution: either GitHub+CRDTs or `git` **`send-email`** + +--- + +### Plain text formats + +> Git is highly optimized for code and similar line-based text file + +It even pulls software to the plain text direction, e.g.: +- delivery-templates +- `common-core.protocols.config` + +Why not exploit that more? + +--- + +### Ditching of web applications + +> The architecture of web apps remains fundamentally server-centric + +Disagree. Contrast [PouchDB][pouchdb] with Android [Instant Apps][instant-apps] + +[pouchdb]: https://pouchdb.com/ +[instant-apps]: https://developer.android.com/topic/google-play-instant + +??? + +Talk on dynamic content + +--- + +### Costs are underrated + +- storage +- backups +- maintenance + +Example: blog vs vlog + +--- + +### Real-time collaboration a bit overrated + +It is only possible on the presence of reliable, medium-quality network +connection + +> X also works when inside an elevator, subway or plane! + + + +--- + +### On CRDTs and developer experience + +> For an app developer, how does the use of a CRDT-based data layer compare to +> existing storage layers like a SQL database, a filesystem, or CoreData? Is a +> distributed system harder to write software for? + +Yes. + +See "[A Note on Distributed Computing][note-dist-comp]" + +[note-dist-comp]: https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf + +--- + +## Conclusion + +Why this is a "paper I love": it took offline-first and ran with it. + +But a pinch of CRDT won't make the world local-first. + +The tricky part is the end of the sentence: "**in spite of the Cloud**". + +--- + +## Thank you! + +References: + +1. these slides: [{{ site.tld }}/slides.html]({% link slides.md %}) +2. [prose version of this presentation]({% link _articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md %}) +3. "[Local-First Software: You Own Your Data, in spite of the Cloud](https://martin.kleppmann.com/papers/local-first.pdf)", + by M. Kleppmann, A. Wiggins, P. Van Hardenberg and M. F. McGranaghan +4. [The Morning Paper](https://blog.acolyer.org/2019/11/20/local-first-software/) + article +5. "[A Note on Distributed Computing][note-dist-comp]", by J. Waldo, G. Wyant, A. Wollrath and S Kendall + +[note-dist-comp]: https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf diff --git a/locale/eo/LC_MESSAGES/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.po b/locale/eo/LC_MESSAGES/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.po new file mode 100644 index 0000000..ade1529 --- /dev/null +++ b/locale/eo/LC_MESSAGES/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.po @@ -0,0 +1,497 @@ +# +msgid "" +msgstr "" + +msgid "" +"title: \"Local-First Software: You Own Your Data, in spite of the Cloud - " +"article review\"" +msgstr "" + +msgid "date: 2020-11-14" +msgstr "" + +msgid "layout: post" +msgstr "" + +msgid "lang: en" +msgstr "" + +msgid "" +"ref: local-first-software-you-own-your-data-in-spite-of-the-cloud-article-" +"review" +msgstr "" + +msgid "eu_categories: presentation,article review" +msgstr "" + +msgid "" +"*This article is derived from a [presentation][presentation] given at a " +"Papers We Love meetup on the same subject.*" +msgstr "" + +msgid "" +"This is a review of the article \"[Local-First Software: You Own Your Data, " +"in spite of the Cloud][article-pdf]\", by M. Kleppmann, A. Wiggins, P. Van " +"Hardenberg and M. F. McGranaghan." +msgstr "" + +msgid "Offline-first, local-first" +msgstr "" + +msgid "" +"The \"local-first\" term they use isn't new, and I have used it myself in " +"the past to refer to this types of application, where the data lives " +"primarily on the client, and there are conflict resolution algorithms that " +"reconcile data created on different instances." +msgstr "" + +msgid "" +"Sometimes I see confusion with this idea and \"client-side\", \"offline-" +"friendly\", \"syncable\", etc. I have myself used this terms, also." +msgstr "" + +msgid "" +"There exists, however, already the \"offline-first\" term, which conveys " +"almost all of that meaning. In my view, \"local-first\" doesn't extend " +"\"offline-first\" in any aspect, rather it gives a well-defined meaning to " +"it instead. I could say that \"local-first\" is just \"offline-first\", but " +"with 7 well-defined ideals instead of community best practices." +msgstr "" + +msgid "" +"[presentation]: {% link _slides/2020-11-14-on-local-first-beyond-the-crdt-" +"silver-bullet.slides %} [article-pdf]: " +"https://martin.kleppmann.com/papers/local-first.pdf" +msgstr "" + +msgid "Software licenses" +msgstr "" + +msgid "" +"On a footnote of the 7th ideal (\"You Retain Ultimate Ownership and " +"Control\"), the authors say:" +msgstr "" + +msgid "" +"In our opinion, maintaining control and ownership of data does not mean that" +" the software must necessarily be open source. (...) as long as it does not " +"artificially restrict what users can do with their files." +msgstr "" + +msgid "" +"#!/bin/sh\n" +"\n" +"TODAY=$(date +%s)\n" +"LICENSE_EXPIRATION=$(date -d 2020-11-15 +%s)\n" +"\n" +"if [ $TODAY -ge $LICENSE_EXPIRATION ]; then\n" +" echo 'License expired!'\n" +" exit 1\n" +"fi\n" +"\n" +"echo $((2 + 2))\n" +msgstr "" + +msgid "Now when using this very useful program:" +msgstr "" + +msgid "" +"# today\n" +"$ ./useful-adder.sh\n" +"4\n" +"# tomorrow\n" +"$ ./useful-adder.sh\n" +"License expired!\n" +msgstr "" + +msgid "" +"This is obviously an intentional restriction, and it goes against the 5th " +"ideal (\"The Long Now\"). This software would only be useful as long as the " +"embedded license expiration allowed. Sure you could change the clock on the " +"computer, but there are many other ways that this type of intentional " +"restriction is in conflict with that ideal." +msgstr "" + +msgid "" +"However, what about unintentional restrictions? What if a software had an " +"equal or similar restriction, and stopped working after days pass? Or what " +"if the programmer added a constant to make the development simpler, and this" +" led to unintentionally restricting the user?" +msgstr "" + +msgid "" +"# today\n" +"$ useful-program\n" +"# ...useful output...\n" +"\n" +"# tomorrow, with more data\n" +"$ useful-program\n" +"ERROR: Panic! Stack overflow!\n" +msgstr "" + +msgid "" +"The point is: if the software isn't free/libre, \"The Long Now\" isn't " +"achievable without a lot of wishful thinking. Maybe the authors were trying " +"to be more friendly towards business who don't like FOSS, but in doing so " +"they've proposed a contradiction by reconciling \"The Long Now\" with " +"proprietary software." +msgstr "" + +msgid "" +"It isn't the same as saying that any free/libre software achieves that " +"ideal, either. The license can still be free, but the source code can become" +" unavailable due to cloud rot. Or maybe the build is undocumented, or the " +"build tools had specific configuration that one has to guess. A piece of " +"free/libre software can still fail to achieve \"The Long Now\". Being free " +"doesn't guarantee it, just makes it possible." +msgstr "" + +msgid "" +"An open specification could serve as a blueprint to other implementations, " +"making the data format more friendly to reverse-engineering. But the re-" +"implementation still has to exist, at which point the original software " +"failed to achieve \"The Long Now\"." +msgstr "" + +msgid "It is less bad, but still not quite there yet." +msgstr "" + +msgid "Denial of existing solutions" +msgstr "" + +msgid "" +"When describing \"Existing Data Storage and Sharing Models\", on a " +"footnote[^devil] the authors say:" +msgstr "" + +msgid "" +"[^devil]: This is the second aspect that I'm picking on the article from a " +"footnote. I guess the devil really is on the details." +msgstr "" + +msgid "" +"In principle it is possible to collaborate without a repository service, " +"e.g. by sending patch files by email, but the majority of Git users rely on " +"GitHub." +msgstr "" + +msgid "" +"The authors go to a great length to talk about usability of cloud apps, and " +"even point to research they've done on it, but they've missed learning more " +"from local-first solutions that already exist." +msgstr "" + +msgid "" +"Say the automerge CRDT proves to be even more useful than what everybody " +"imagined. Say someone builds a local-first repository service using it. How " +"will it change anything of the Git/GitHub model? What is different about it " +"that prevents people in the future writing a paper saying:" +msgstr "" + +msgid "" +"In principle it is possible to collaborate without a repository service, " +"e.g. by using automerge and platform X, but the majority of Git users rely " +"on GitHub." +msgstr "" + +msgid "How is this any better?" +msgstr "" + +msgid "" +"If it is already [possible](https://drewdevault.com/2018/07/23/Git-is-" +"already-distributed.html) to have a local-first development workflow, why " +"don't people use it? Is it just fashion, or there's a fundamental problem " +"with it? If so, what is it, and how to avoid it?" +msgstr "" + +msgid "" +"If sending patches by emails is perfectly possible but out of fashion, why " +"even talk about Git/GitHub? Isn't this a problem that people are putting " +"themselves in? How can CRDTs possibly prevent people from doing that?" +msgstr "" + +msgid "" +"My impression is that the authors envision a better future, where " +"development is fully decentralized unlike today, and somehow CRDTs will make" +" that happen. If more people think this way, \"CRDT\" is next in line to the" +" buzzword list that solves everything, like \"containers\", \"blockchain\" " +"or \"machine learning\"." +msgstr "" + +msgid "" +"Rather than picturing an imaginary service that could be described like " +"\"GitHub+CRDTs\" and people would adopt it, I'd rather better understand why" +" people don't do it already, since Git is built to work like that." +msgstr "" + +msgid "Ditching of web applications" +msgstr "" + +msgid "" +"The authors put web application in a worse position for building local-first" +" application, claiming that:" +msgstr "" + +msgid "" +"(...) the architecture of web apps remains fundamentally server-centric. " +"Offline support is an afterthought in most web apps, and the result is " +"accordingly fragile." +msgstr "" + +msgid "Well, I disagree." +msgstr "" + +msgid "" +"The problem isn't inherit to the web platform, but instead how people use " +"it." +msgstr "" + +msgid "" +"I have myself built offline-first applications, leveraging IndexedDB, App " +"Cache, *etc*. I wanted to build an offline-first application on the web, and" +" so I did." +msgstr "" + +msgid "" +"In fact, many people choose [PouchDB](https://pouchdb.com/) *because* of " +"that, since it is a good tool for offline-first web applications. The " +"problem isn't really the technology, but how much people want their " +"application to be local-first." +msgstr "" + +msgid "" +"Contrast it with Android [Instant " +"Apps](https://developer.android.com/topic/google-play-instant), where " +"applications are sent to the phone in small parts. Since this requires an " +"internet connection to move from a part of the app bundle to another, a " +"subset of the app isn't local-first, despite being an app." +msgstr "" + +msgid "" +"The point isn't the technology, but how people are using it. Local-first web" +" applications are perfectly possible, just like non-local-first native " +"applications are possible." +msgstr "" + +msgid "Costs are underrated" +msgstr "" + +msgid "" +"I think the costs of \"old-fashioned apps\" over \"cloud apps\" are " +"underrated, mainly regarding storage, and that this costs can vary a lot by " +"application." +msgstr "" + +msgid "" +"Say a person writes online articles for their personal website, and puts " +"everything into Git. Since there isn't supposed to be any collaboration, all" +" of the relevant ideals of local-first are achieved." +msgstr "" + +msgid "" +"Now another person creates videos instead of articles. They could try " +"keeping everything local, but after some time the storage usage fills the " +"entire disk. This person's local-first setup would be much more complex, and" +" would cost much more on maintenance, backup and storage." +msgstr "" + +msgid "" +"Even though both have similar needs, a local-first video repository is much " +"more demanding. So the local-first thinking here isn't \"just keep " +"everything local\", but \"how much time and money am I willing to spend to " +"keep everything local\"." +msgstr "" + +msgid "" +"The convenience of \"cloud apps\" becomes so attractive that many don't even" +" have a local copy of their videos, and rely exclusively on service " +"providers to maintain, backup and store their content." +msgstr "" + +msgid "" +"The dial measuring \"cloud apps\" and \"old-fashioned apps\" needs to be " +"specific to use-cases." +msgstr "" + +msgid "Real-time collaboration is optional" +msgstr "" + +msgid "" +"If I were the one making the list of ideals, I wouldn't focus so much on " +"real-time collaboration." +msgstr "" + +msgid "" +"Even though seamless collaboration is desired, it being real-time depends on" +" the network being available for that. But ideal 3 states that \"The Network" +" is Optional\", so real-time collaboration is also optional." +msgstr "" + +msgid "" +"The fundamentals of a local-first system should enable real-time " +"collaboration when network is available, but shouldn't focus on it." +msgstr "" + +msgid "" +"On many places when discussing applications being offline, it is common for " +"me to find people saying that their application works \"even on a plane, " +"subway or elevator\". That is a reflection of when said developers have to " +"deal with networks being unavailable." +msgstr "" + +msgid "" +"When discussing \"working offline\", I'd rather keep this type of person in " +"mind, then the subset of people who are offline when on the elevator will " +"naturally be included." +msgstr "" + +msgid "On CRDTs and developer experience" +msgstr "" + +msgid "" +"When discussing developer experience, the authors bring up some questions to" +" be answered further, like:" +msgstr "" + +msgid "" +"For an app developer, how does the use of a CRDT-based data layer compare to" +" existing storage layers like a SQL database, a filesystem, or CoreData? Is " +"a distributed system harder to write software for?" +msgstr "" + +msgid "That is an easy one: yes." +msgstr "" + +msgid "" +"A distributed system *is* harder to write software for, being a distributed " +"system." +msgstr "" + +msgid "Conclusion" +msgstr "" + +msgid "" +"I liked a lot the article, as it took the \"offline-first\" philosophy and " +"ran with it." +msgstr "" + +msgid "" +"But I think the authors' view of adding CRDTs and things becoming local-" +"first is a bit too magical." +msgstr "" + +msgid "" +"It is a step forward, and given the number of times I've seen the paper " +"shared around I think there's a chance people will prefer saying \"local-" +"first\" in *lieu* of \"offline-first\" from now on." +msgstr "" + +msgid "" +"They give examples of artificial restrictions, like this artificial " +"restriction I've come up with:" +msgstr "" + +msgid "" +"Just as easily as I can come up with ways to intentionally restrict users, I" +" can do the same for unintentionally restrictions. A program can stop " +"working for a variety of reasons." +msgstr "" + +msgid "" +"If it stops working due do, say, data growth, what are the options? " +"Reverting to an earlier backup, and making it read-only? That isn't really a" +" \"Long Now\", but rather a \"Long Now as long as the software keeps working" +" as expected\"." +msgstr "" + +msgid "" +"A colleague has challenged my view, arguing that the software doesn't really" +" need to be free, as long as there is an specification of the file format. " +"This way if the software stops working, the format can still be processed by" +" other programs. But this doesn't apply in practice: if you have a document " +"that you write to, and software stops working, you still want to write to " +"the document. An external tool that navigates the content and shows it to " +"you won't allow you to keep writing, and when it does that tool is now " +"starting to re-implement the software." +msgstr "" + +msgid "" +"But this leaves out a big chunk of the world where internet connection is " +"intermittent, or only works every other day or only once a week, or stops " +"working when it rains, *etc*. For this audience, living without network " +"connectivity isn't such a discrete moment in time, but part of every day " +"life. I like the fact that the authors acknowledge that." +msgstr "" + +msgid "" +"Adding a large layer of data structures and algorithms will make it more " +"complex to write software for, naturally. And if trying to make this layer " +"transparent to the programmer, so they can pretend that layer doesn't exist " +"is a bad idea, as RPC frameworks have tried, and failed." +msgstr "" + +msgid "" +"See \"[A Note on Distributed " +"Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\"" +" for a critique on RPC frameworks trying to make the network invisible, " +"which I think also applies in equivalence for making the CRDTs layer " +"invisible." +msgstr "" + +msgid "" +"This particular area is one that I have large interest on, and I wish to see" +" more being done on the \"local-first\" space." +msgstr "" + +#~ msgid "They give examples of artificial restrictions, like this one:" +#~ msgstr "" + +#~ msgid "" +#~ "Just as easily as I can come up with ways to intentionally restrict users, " +#~ "just as easily I can do the same for unintentionally restricting users. A " +#~ "program can stop working for a variety of reasons." +#~ msgstr "" + +#~ msgid "" +#~ "If it stops working due do data growth, what are the options? Reverting to " +#~ "an earlier backup, and making it read-only? That isn't really a \"Long " +#~ "Now\", but rather a \"Long Now as long as the software keeps working as " +#~ "expected\"." +#~ msgstr "" + +#~ msgid "" +#~ "A colleague has challenged my view, arguing that the software doesn't really" +#~ " need to be free, as long as there is an specification of the file format. " +#~ "This way is the software stops working, the format can still be processed by" +#~ " other programs. But this doesn't apply in practice: if you have a document " +#~ "that you write to, and software stops working, you still want to write to " +#~ "the document. An external tool that navigates the content and shows it to " +#~ "you won't allow you to keep writing, and when it does that tool is now " +#~ "starting to re-implement the software." +#~ msgstr "" + +#~ msgid "" +#~ "But this leaves out a big chunk of the world where internet connection is " +#~ "intermittent, or only work every other day or only once a week, or stops " +#~ "working when it rains, *etc*. For this audience, living without network " +#~ "connectivity isn't such a discrete moment in time, but part of every day " +#~ "life. I like the fact that the authors acknowledge that." +#~ msgstr "" + +#~ msgid "" +#~ "Adding a large layer of data structures and algorithms will make it more " +#~ "complex to write software for, naturally. And if trying to make this layer " +#~ "transparent to the programmer, so they can pretend that layer doesn't exist " +#~ "is a bad idea, as RPC frameworks have tried, and failed. See \"[A Note on " +#~ "Distributed " +#~ "Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\"" +#~ " for a critique on RPC frameworks trying to make the network invisible, " +#~ "which I think also applies in equivalence for making the CRDTs layer " +#~ "invisible." +#~ msgstr "" + +#~ msgid "" +#~ "It is a step forward, and given the number of times I've seen the paper " +#~ "shared around I think there's a chance people will prefer saying \"local-" +#~ "first\" in lieu of \"offline-first\" from now on." +#~ msgstr "" diff --git a/locale/eo/LC_MESSAGES/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides.po b/locale/eo/LC_MESSAGES/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides.po new file mode 100644 index 0000000..7674704 --- /dev/null +++ b/locale/eo/LC_MESSAGES/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides.po @@ -0,0 +1,322 @@ +# +msgid "" +msgstr "" + +msgid "title: 'On \"local-first\": beyond the CRDT silver bullet'" +msgstr "" + +msgid "date: 2020-11-14" +msgstr "" + +msgid "layout: slides" +msgstr "" + +msgid "lang: en" +msgstr "" + +msgid "ref: on-local-first-beyond-the-crdt-silver-bullet" +msgstr "" + +msgid "On local-first" +msgstr "" + +msgid "Beyond the CRDT silver bullet" +msgstr "" + +msgid "Part 1" +msgstr "" + +msgid "Exposition" +msgstr "" + +msgid "\"cloud apps\" vs \"old-fashioned apps\"" +msgstr "" + +msgid "Target" +msgstr "" + +msgid "documents" +msgstr "" + +msgid "files" +msgstr "" + +msgid "personal data repositories" +msgstr "" + +msgid "" +"Not: banking services, e-commerce, social networking, ride-sharing, *etc*." +msgstr "" + +msgid "7 Ideals for local-first software" +msgstr "" + +msgid "1 - No Spinners: Your Work at Your Fingertips" +msgstr "" + +msgid "2 - Your Work Is Not Trapped on One Device" +msgstr "" + +msgid "3 - The Network Is Optional" +msgstr "" + +msgid "4 - Seamless Collaboration with Your Colleagues" +msgstr "" + +msgid "5 - The Long Now" +msgstr "" + +msgid "6 - Security and Privacy by Default" +msgstr "" + +msgid "7 - You Retain Ultimate Ownership and Control" +msgstr "" + +msgid "Towards a Better Future" +msgstr "" + +msgid "" +"CRDTs (Conflict-free Replicated Data Types) as a Foundational Technology" +msgstr "" + +msgid "Use case" +msgstr "" + +msgid "" +"# in node A and node B\n" +"s = \"Hello, World\"\n" +"\n" +"# in node A\n" +"s = \"Hello, Alice\"\n" +"\n" +"# in node B\n" +"s = \"Hello, Bob\"\n" +msgstr "" + +msgid "How to reconcile those?" +msgstr "" + +msgid "`Hello, ABloibce`" +msgstr "" + +msgid "`Hello, AliceBob`" +msgstr "" + +msgid "`Hello, BobAlice`" +msgstr "" + +msgid "`Hello, Alice`" +msgstr "" + +msgid "`Hello, Bob`" +msgstr "" + +msgid "Existing CRDTs differ:" +msgstr "" + +msgid "performance" +msgstr "" + +msgid "storage" +msgstr "" + +msgid "compression" +msgstr "" + +msgid "metadata overhead" +msgstr "" + +msgid "Hint towards the \"automerge\" CRDT" +msgstr "" + +msgid "*show comparison table, page 9*" +msgstr "" + +msgid "Part 2" +msgstr "" + +msgid "Critique" +msgstr "" + +msgid "Software license" +msgstr "" + +msgid "" +"In our opinion, maintaining control and ownership of data does not mean that" +" the software must necessarily be open source." +msgstr "" + +msgid "Example 1 - intentional restriction" +msgstr "" + +msgid "" +"#!/bin/sh\n" +"\n" +"TODAY=$(date +%s)\n" +"LICENSE_EXPIRATION=$(date -d 2020-10-27 +%s)\n" +"\n" +"if [ $TODAY -ge $LICENSE_EXPIRATION ]; then\n" +" echo 'License expired!'\n" +" exit 1\n" +"fi\n" +"\n" +"echo $((2 + 2))\n" +msgstr "" + +msgid "" +"# today\n" +"$ ./useful-adder.sh\n" +"4\n" +"# tomorrow\n" +"$ ./useful-adder.sh\n" +"License expired!\n" +msgstr "" + +msgid "Example 2 - unintentional restriction" +msgstr "" + +msgid "" +"# today\n" +"$ useful-program\n" +"# ...useful output...\n" +"\n" +"# tomorrow, with more data\n" +"$ useful-program\n" +"ERROR: Panic! Stack overflow!\n" +msgstr "" + +msgid "local-first **requires** free/libre software" +msgstr "" + +msgid "Otherwise \"The Long Now\" (ideal nº5) is lost" +msgstr "" + +msgid "Denial of existing solutions" +msgstr "" + +msgid "" +"In principle it is possible to collaborate without a repository service, " +"e.g. by sending patch files by email, but the majority of Git users rely on " +"GitHub." +msgstr "" + +msgid "Solution: either GitHub+CRDTs or `git` **`send-email`**" +msgstr "" + +msgid "Plain text formats" +msgstr "" + +msgid "Git is highly optimized for code and similar line-based text file" +msgstr "" + +msgid "It even pulls software to the plain text direction, e.g.:" +msgstr "" + +msgid "delivery-templates" +msgstr "" + +msgid "`common-core.protocols.config`" +msgstr "" + +msgid "Why not exploit that more?" +msgstr "" + +msgid "Ditching of web applications" +msgstr "" + +msgid "The architecture of web apps remains fundamentally server-centric" +msgstr "" + +msgid "" +"Disagree. Contrast [PouchDB](https://pouchdb.com/) with Android [Instant " +"Apps](https://developer.android.com/topic/google-play-instant)" +msgstr "" + +msgid "???" +msgstr "" + +msgid "Talk on dynamic content" +msgstr "" + +msgid "Costs are underrated" +msgstr "" + +msgid "backups" +msgstr "" + +msgid "maintenance" +msgstr "" + +msgid "Example: blog vs vlog" +msgstr "" + +msgid "Real-time collaboration a bit overrated" +msgstr "" + +msgid "" +"It is only possible on the presence of reliable, medium-quality network " +"connection" +msgstr "" + +msgid "X also works when inside an elevator, subway or plane!" +msgstr "" + +msgid "On CRDTs and developer experience" +msgstr "" + +msgid "" +"For an app developer, how does the use of a CRDT-based data layer compare to" +" existing storage layers like a SQL database, a filesystem, or CoreData? Is " +"a distributed system harder to write software for?" +msgstr "" + +msgid "Yes." +msgstr "" + +msgid "" +"See \"[A Note on Distributed " +"Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\"" +msgstr "" + +msgid "Conclusion" +msgstr "" + +msgid "Why this is a \"paper I love\": it took offline-first and ran with it." +msgstr "" + +msgid "But a pinch of CRDT won't make the world local-first." +msgstr "" + +msgid "The tricky part is the end of the sentence: \"**in spite of the Cloud**\"." +msgstr "" + +msgid "Thank you!" +msgstr "" + +msgid "References:" +msgstr "" + +msgid "these slides: [{{ site.tld }}/slides.html]({% link slides.md %})" +msgstr "" + +msgid "" +"[prose version of this presentation]({% link _articles/2020-11-14-local-" +"first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md %})" +msgstr "" + +msgid "" +"\"[Local-First Software: You Own Your Data, in spite of the " +"Cloud](https://martin.kleppmann.com/papers/local-first.pdf)\", by M. " +"Kleppmann, A. Wiggins, P. Van Hardenberg and M. F. McGranaghan" +msgstr "" + +msgid "" +"[The Morning Paper](https://blog.acolyer.org/2019/11/20/local-first-" +"software/) article" +msgstr "" + +msgid "" +"\"[A Note on Distributed " +"Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\"," +" by J. Waldo, G. Wyant, A. Wollrath and S Kendall" +msgstr "" diff --git a/locale/fr/LC_MESSAGES/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.po b/locale/fr/LC_MESSAGES/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.po new file mode 100644 index 0000000..ade1529 --- /dev/null +++ b/locale/fr/LC_MESSAGES/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.po @@ -0,0 +1,497 @@ +# +msgid "" +msgstr "" + +msgid "" +"title: \"Local-First Software: You Own Your Data, in spite of the Cloud - " +"article review\"" +msgstr "" + +msgid "date: 2020-11-14" +msgstr "" + +msgid "layout: post" +msgstr "" + +msgid "lang: en" +msgstr "" + +msgid "" +"ref: local-first-software-you-own-your-data-in-spite-of-the-cloud-article-" +"review" +msgstr "" + +msgid "eu_categories: presentation,article review" +msgstr "" + +msgid "" +"*This article is derived from a [presentation][presentation] given at a " +"Papers We Love meetup on the same subject.*" +msgstr "" + +msgid "" +"This is a review of the article \"[Local-First Software: You Own Your Data, " +"in spite of the Cloud][article-pdf]\", by M. Kleppmann, A. Wiggins, P. Van " +"Hardenberg and M. F. McGranaghan." +msgstr "" + +msgid "Offline-first, local-first" +msgstr "" + +msgid "" +"The \"local-first\" term they use isn't new, and I have used it myself in " +"the past to refer to this types of application, where the data lives " +"primarily on the client, and there are conflict resolution algorithms that " +"reconcile data created on different instances." +msgstr "" + +msgid "" +"Sometimes I see confusion with this idea and \"client-side\", \"offline-" +"friendly\", \"syncable\", etc. I have myself used this terms, also." +msgstr "" + +msgid "" +"There exists, however, already the \"offline-first\" term, which conveys " +"almost all of that meaning. In my view, \"local-first\" doesn't extend " +"\"offline-first\" in any aspect, rather it gives a well-defined meaning to " +"it instead. I could say that \"local-first\" is just \"offline-first\", but " +"with 7 well-defined ideals instead of community best practices." +msgstr "" + +msgid "" +"[presentation]: {% link _slides/2020-11-14-on-local-first-beyond-the-crdt-" +"silver-bullet.slides %} [article-pdf]: " +"https://martin.kleppmann.com/papers/local-first.pdf" +msgstr "" + +msgid "Software licenses" +msgstr "" + +msgid "" +"On a footnote of the 7th ideal (\"You Retain Ultimate Ownership and " +"Control\"), the authors say:" +msgstr "" + +msgid "" +"In our opinion, maintaining control and ownership of data does not mean that" +" the software must necessarily be open source. (...) as long as it does not " +"artificially restrict what users can do with their files." +msgstr "" + +msgid "" +"#!/bin/sh\n" +"\n" +"TODAY=$(date +%s)\n" +"LICENSE_EXPIRATION=$(date -d 2020-11-15 +%s)\n" +"\n" +"if [ $TODAY -ge $LICENSE_EXPIRATION ]; then\n" +" echo 'License expired!'\n" +" exit 1\n" +"fi\n" +"\n" +"echo $((2 + 2))\n" +msgstr "" + +msgid "Now when using this very useful program:" +msgstr "" + +msgid "" +"# today\n" +"$ ./useful-adder.sh\n" +"4\n" +"# tomorrow\n" +"$ ./useful-adder.sh\n" +"License expired!\n" +msgstr "" + +msgid "" +"This is obviously an intentional restriction, and it goes against the 5th " +"ideal (\"The Long Now\"). This software would only be useful as long as the " +"embedded license expiration allowed. Sure you could change the clock on the " +"computer, but there are many other ways that this type of intentional " +"restriction is in conflict with that ideal." +msgstr "" + +msgid "" +"However, what about unintentional restrictions? What if a software had an " +"equal or similar restriction, and stopped working after days pass? Or what " +"if the programmer added a constant to make the development simpler, and this" +" led to unintentionally restricting the user?" +msgstr "" + +msgid "" +"# today\n" +"$ useful-program\n" +"# ...useful output...\n" +"\n" +"# tomorrow, with more data\n" +"$ useful-program\n" +"ERROR: Panic! Stack overflow!\n" +msgstr "" + +msgid "" +"The point is: if the software isn't free/libre, \"The Long Now\" isn't " +"achievable without a lot of wishful thinking. Maybe the authors were trying " +"to be more friendly towards business who don't like FOSS, but in doing so " +"they've proposed a contradiction by reconciling \"The Long Now\" with " +"proprietary software." +msgstr "" + +msgid "" +"It isn't the same as saying that any free/libre software achieves that " +"ideal, either. The license can still be free, but the source code can become" +" unavailable due to cloud rot. Or maybe the build is undocumented, or the " +"build tools had specific configuration that one has to guess. A piece of " +"free/libre software can still fail to achieve \"The Long Now\". Being free " +"doesn't guarantee it, just makes it possible." +msgstr "" + +msgid "" +"An open specification could serve as a blueprint to other implementations, " +"making the data format more friendly to reverse-engineering. But the re-" +"implementation still has to exist, at which point the original software " +"failed to achieve \"The Long Now\"." +msgstr "" + +msgid "It is less bad, but still not quite there yet." +msgstr "" + +msgid "Denial of existing solutions" +msgstr "" + +msgid "" +"When describing \"Existing Data Storage and Sharing Models\", on a " +"footnote[^devil] the authors say:" +msgstr "" + +msgid "" +"[^devil]: This is the second aspect that I'm picking on the article from a " +"footnote. I guess the devil really is on the details." +msgstr "" + +msgid "" +"In principle it is possible to collaborate without a repository service, " +"e.g. by sending patch files by email, but the majority of Git users rely on " +"GitHub." +msgstr "" + +msgid "" +"The authors go to a great length to talk about usability of cloud apps, and " +"even point to research they've done on it, but they've missed learning more " +"from local-first solutions that already exist." +msgstr "" + +msgid "" +"Say the automerge CRDT proves to be even more useful than what everybody " +"imagined. Say someone builds a local-first repository service using it. How " +"will it change anything of the Git/GitHub model? What is different about it " +"that prevents people in the future writing a paper saying:" +msgstr "" + +msgid "" +"In principle it is possible to collaborate without a repository service, " +"e.g. by using automerge and platform X, but the majority of Git users rely " +"on GitHub." +msgstr "" + +msgid "How is this any better?" +msgstr "" + +msgid "" +"If it is already [possible](https://drewdevault.com/2018/07/23/Git-is-" +"already-distributed.html) to have a local-first development workflow, why " +"don't people use it? Is it just fashion, or there's a fundamental problem " +"with it? If so, what is it, and how to avoid it?" +msgstr "" + +msgid "" +"If sending patches by emails is perfectly possible but out of fashion, why " +"even talk about Git/GitHub? Isn't this a problem that people are putting " +"themselves in? How can CRDTs possibly prevent people from doing that?" +msgstr "" + +msgid "" +"My impression is that the authors envision a better future, where " +"development is fully decentralized unlike today, and somehow CRDTs will make" +" that happen. If more people think this way, \"CRDT\" is next in line to the" +" buzzword list that solves everything, like \"containers\", \"blockchain\" " +"or \"machine learning\"." +msgstr "" + +msgid "" +"Rather than picturing an imaginary service that could be described like " +"\"GitHub+CRDTs\" and people would adopt it, I'd rather better understand why" +" people don't do it already, since Git is built to work like that." +msgstr "" + +msgid "Ditching of web applications" +msgstr "" + +msgid "" +"The authors put web application in a worse position for building local-first" +" application, claiming that:" +msgstr "" + +msgid "" +"(...) the architecture of web apps remains fundamentally server-centric. " +"Offline support is an afterthought in most web apps, and the result is " +"accordingly fragile." +msgstr "" + +msgid "Well, I disagree." +msgstr "" + +msgid "" +"The problem isn't inherit to the web platform, but instead how people use " +"it." +msgstr "" + +msgid "" +"I have myself built offline-first applications, leveraging IndexedDB, App " +"Cache, *etc*. I wanted to build an offline-first application on the web, and" +" so I did." +msgstr "" + +msgid "" +"In fact, many people choose [PouchDB](https://pouchdb.com/) *because* of " +"that, since it is a good tool for offline-first web applications. The " +"problem isn't really the technology, but how much people want their " +"application to be local-first." +msgstr "" + +msgid "" +"Contrast it with Android [Instant " +"Apps](https://developer.android.com/topic/google-play-instant), where " +"applications are sent to the phone in small parts. Since this requires an " +"internet connection to move from a part of the app bundle to another, a " +"subset of the app isn't local-first, despite being an app." +msgstr "" + +msgid "" +"The point isn't the technology, but how people are using it. Local-first web" +" applications are perfectly possible, just like non-local-first native " +"applications are possible." +msgstr "" + +msgid "Costs are underrated" +msgstr "" + +msgid "" +"I think the costs of \"old-fashioned apps\" over \"cloud apps\" are " +"underrated, mainly regarding storage, and that this costs can vary a lot by " +"application." +msgstr "" + +msgid "" +"Say a person writes online articles for their personal website, and puts " +"everything into Git. Since there isn't supposed to be any collaboration, all" +" of the relevant ideals of local-first are achieved." +msgstr "" + +msgid "" +"Now another person creates videos instead of articles. They could try " +"keeping everything local, but after some time the storage usage fills the " +"entire disk. This person's local-first setup would be much more complex, and" +" would cost much more on maintenance, backup and storage." +msgstr "" + +msgid "" +"Even though both have similar needs, a local-first video repository is much " +"more demanding. So the local-first thinking here isn't \"just keep " +"everything local\", but \"how much time and money am I willing to spend to " +"keep everything local\"." +msgstr "" + +msgid "" +"The convenience of \"cloud apps\" becomes so attractive that many don't even" +" have a local copy of their videos, and rely exclusively on service " +"providers to maintain, backup and store their content." +msgstr "" + +msgid "" +"The dial measuring \"cloud apps\" and \"old-fashioned apps\" needs to be " +"specific to use-cases." +msgstr "" + +msgid "Real-time collaboration is optional" +msgstr "" + +msgid "" +"If I were the one making the list of ideals, I wouldn't focus so much on " +"real-time collaboration." +msgstr "" + +msgid "" +"Even though seamless collaboration is desired, it being real-time depends on" +" the network being available for that. But ideal 3 states that \"The Network" +" is Optional\", so real-time collaboration is also optional." +msgstr "" + +msgid "" +"The fundamentals of a local-first system should enable real-time " +"collaboration when network is available, but shouldn't focus on it." +msgstr "" + +msgid "" +"On many places when discussing applications being offline, it is common for " +"me to find people saying that their application works \"even on a plane, " +"subway or elevator\". That is a reflection of when said developers have to " +"deal with networks being unavailable." +msgstr "" + +msgid "" +"When discussing \"working offline\", I'd rather keep this type of person in " +"mind, then the subset of people who are offline when on the elevator will " +"naturally be included." +msgstr "" + +msgid "On CRDTs and developer experience" +msgstr "" + +msgid "" +"When discussing developer experience, the authors bring up some questions to" +" be answered further, like:" +msgstr "" + +msgid "" +"For an app developer, how does the use of a CRDT-based data layer compare to" +" existing storage layers like a SQL database, a filesystem, or CoreData? Is " +"a distributed system harder to write software for?" +msgstr "" + +msgid "That is an easy one: yes." +msgstr "" + +msgid "" +"A distributed system *is* harder to write software for, being a distributed " +"system." +msgstr "" + +msgid "Conclusion" +msgstr "" + +msgid "" +"I liked a lot the article, as it took the \"offline-first\" philosophy and " +"ran with it." +msgstr "" + +msgid "" +"But I think the authors' view of adding CRDTs and things becoming local-" +"first is a bit too magical." +msgstr "" + +msgid "" +"It is a step forward, and given the number of times I've seen the paper " +"shared around I think there's a chance people will prefer saying \"local-" +"first\" in *lieu* of \"offline-first\" from now on." +msgstr "" + +msgid "" +"They give examples of artificial restrictions, like this artificial " +"restriction I've come up with:" +msgstr "" + +msgid "" +"Just as easily as I can come up with ways to intentionally restrict users, I" +" can do the same for unintentionally restrictions. A program can stop " +"working for a variety of reasons." +msgstr "" + +msgid "" +"If it stops working due do, say, data growth, what are the options? " +"Reverting to an earlier backup, and making it read-only? That isn't really a" +" \"Long Now\", but rather a \"Long Now as long as the software keeps working" +" as expected\"." +msgstr "" + +msgid "" +"A colleague has challenged my view, arguing that the software doesn't really" +" need to be free, as long as there is an specification of the file format. " +"This way if the software stops working, the format can still be processed by" +" other programs. But this doesn't apply in practice: if you have a document " +"that you write to, and software stops working, you still want to write to " +"the document. An external tool that navigates the content and shows it to " +"you won't allow you to keep writing, and when it does that tool is now " +"starting to re-implement the software." +msgstr "" + +msgid "" +"But this leaves out a big chunk of the world where internet connection is " +"intermittent, or only works every other day or only once a week, or stops " +"working when it rains, *etc*. For this audience, living without network " +"connectivity isn't such a discrete moment in time, but part of every day " +"life. I like the fact that the authors acknowledge that." +msgstr "" + +msgid "" +"Adding a large layer of data structures and algorithms will make it more " +"complex to write software for, naturally. And if trying to make this layer " +"transparent to the programmer, so they can pretend that layer doesn't exist " +"is a bad idea, as RPC frameworks have tried, and failed." +msgstr "" + +msgid "" +"See \"[A Note on Distributed " +"Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\"" +" for a critique on RPC frameworks trying to make the network invisible, " +"which I think also applies in equivalence for making the CRDTs layer " +"invisible." +msgstr "" + +msgid "" +"This particular area is one that I have large interest on, and I wish to see" +" more being done on the \"local-first\" space." +msgstr "" + +#~ msgid "They give examples of artificial restrictions, like this one:" +#~ msgstr "" + +#~ msgid "" +#~ "Just as easily as I can come up with ways to intentionally restrict users, " +#~ "just as easily I can do the same for unintentionally restricting users. A " +#~ "program can stop working for a variety of reasons." +#~ msgstr "" + +#~ msgid "" +#~ "If it stops working due do data growth, what are the options? Reverting to " +#~ "an earlier backup, and making it read-only? That isn't really a \"Long " +#~ "Now\", but rather a \"Long Now as long as the software keeps working as " +#~ "expected\"." +#~ msgstr "" + +#~ msgid "" +#~ "A colleague has challenged my view, arguing that the software doesn't really" +#~ " need to be free, as long as there is an specification of the file format. " +#~ "This way is the software stops working, the format can still be processed by" +#~ " other programs. But this doesn't apply in practice: if you have a document " +#~ "that you write to, and software stops working, you still want to write to " +#~ "the document. An external tool that navigates the content and shows it to " +#~ "you won't allow you to keep writing, and when it does that tool is now " +#~ "starting to re-implement the software." +#~ msgstr "" + +#~ msgid "" +#~ "But this leaves out a big chunk of the world where internet connection is " +#~ "intermittent, or only work every other day or only once a week, or stops " +#~ "working when it rains, *etc*. For this audience, living without network " +#~ "connectivity isn't such a discrete moment in time, but part of every day " +#~ "life. I like the fact that the authors acknowledge that." +#~ msgstr "" + +#~ msgid "" +#~ "Adding a large layer of data structures and algorithms will make it more " +#~ "complex to write software for, naturally. And if trying to make this layer " +#~ "transparent to the programmer, so they can pretend that layer doesn't exist " +#~ "is a bad idea, as RPC frameworks have tried, and failed. See \"[A Note on " +#~ "Distributed " +#~ "Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\"" +#~ " for a critique on RPC frameworks trying to make the network invisible, " +#~ "which I think also applies in equivalence for making the CRDTs layer " +#~ "invisible." +#~ msgstr "" + +#~ msgid "" +#~ "It is a step forward, and given the number of times I've seen the paper " +#~ "shared around I think there's a chance people will prefer saying \"local-" +#~ "first\" in lieu of \"offline-first\" from now on." +#~ msgstr "" diff --git a/locale/fr/LC_MESSAGES/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides.po b/locale/fr/LC_MESSAGES/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides.po new file mode 100644 index 0000000..7674704 --- /dev/null +++ b/locale/fr/LC_MESSAGES/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides.po @@ -0,0 +1,322 @@ +# +msgid "" +msgstr "" + +msgid "title: 'On \"local-first\": beyond the CRDT silver bullet'" +msgstr "" + +msgid "date: 2020-11-14" +msgstr "" + +msgid "layout: slides" +msgstr "" + +msgid "lang: en" +msgstr "" + +msgid "ref: on-local-first-beyond-the-crdt-silver-bullet" +msgstr "" + +msgid "On local-first" +msgstr "" + +msgid "Beyond the CRDT silver bullet" +msgstr "" + +msgid "Part 1" +msgstr "" + +msgid "Exposition" +msgstr "" + +msgid "\"cloud apps\" vs \"old-fashioned apps\"" +msgstr "" + +msgid "Target" +msgstr "" + +msgid "documents" +msgstr "" + +msgid "files" +msgstr "" + +msgid "personal data repositories" +msgstr "" + +msgid "" +"Not: banking services, e-commerce, social networking, ride-sharing, *etc*." +msgstr "" + +msgid "7 Ideals for local-first software" +msgstr "" + +msgid "1 - No Spinners: Your Work at Your Fingertips" +msgstr "" + +msgid "2 - Your Work Is Not Trapped on One Device" +msgstr "" + +msgid "3 - The Network Is Optional" +msgstr "" + +msgid "4 - Seamless Collaboration with Your Colleagues" +msgstr "" + +msgid "5 - The Long Now" +msgstr "" + +msgid "6 - Security and Privacy by Default" +msgstr "" + +msgid "7 - You Retain Ultimate Ownership and Control" +msgstr "" + +msgid "Towards a Better Future" +msgstr "" + +msgid "" +"CRDTs (Conflict-free Replicated Data Types) as a Foundational Technology" +msgstr "" + +msgid "Use case" +msgstr "" + +msgid "" +"# in node A and node B\n" +"s = \"Hello, World\"\n" +"\n" +"# in node A\n" +"s = \"Hello, Alice\"\n" +"\n" +"# in node B\n" +"s = \"Hello, Bob\"\n" +msgstr "" + +msgid "How to reconcile those?" +msgstr "" + +msgid "`Hello, ABloibce`" +msgstr "" + +msgid "`Hello, AliceBob`" +msgstr "" + +msgid "`Hello, BobAlice`" +msgstr "" + +msgid "`Hello, Alice`" +msgstr "" + +msgid "`Hello, Bob`" +msgstr "" + +msgid "Existing CRDTs differ:" +msgstr "" + +msgid "performance" +msgstr "" + +msgid "storage" +msgstr "" + +msgid "compression" +msgstr "" + +msgid "metadata overhead" +msgstr "" + +msgid "Hint towards the \"automerge\" CRDT" +msgstr "" + +msgid "*show comparison table, page 9*" +msgstr "" + +msgid "Part 2" +msgstr "" + +msgid "Critique" +msgstr "" + +msgid "Software license" +msgstr "" + +msgid "" +"In our opinion, maintaining control and ownership of data does not mean that" +" the software must necessarily be open source." +msgstr "" + +msgid "Example 1 - intentional restriction" +msgstr "" + +msgid "" +"#!/bin/sh\n" +"\n" +"TODAY=$(date +%s)\n" +"LICENSE_EXPIRATION=$(date -d 2020-10-27 +%s)\n" +"\n" +"if [ $TODAY -ge $LICENSE_EXPIRATION ]; then\n" +" echo 'License expired!'\n" +" exit 1\n" +"fi\n" +"\n" +"echo $((2 + 2))\n" +msgstr "" + +msgid "" +"# today\n" +"$ ./useful-adder.sh\n" +"4\n" +"# tomorrow\n" +"$ ./useful-adder.sh\n" +"License expired!\n" +msgstr "" + +msgid "Example 2 - unintentional restriction" +msgstr "" + +msgid "" +"# today\n" +"$ useful-program\n" +"# ...useful output...\n" +"\n" +"# tomorrow, with more data\n" +"$ useful-program\n" +"ERROR: Panic! Stack overflow!\n" +msgstr "" + +msgid "local-first **requires** free/libre software" +msgstr "" + +msgid "Otherwise \"The Long Now\" (ideal nº5) is lost" +msgstr "" + +msgid "Denial of existing solutions" +msgstr "" + +msgid "" +"In principle it is possible to collaborate without a repository service, " +"e.g. by sending patch files by email, but the majority of Git users rely on " +"GitHub." +msgstr "" + +msgid "Solution: either GitHub+CRDTs or `git` **`send-email`**" +msgstr "" + +msgid "Plain text formats" +msgstr "" + +msgid "Git is highly optimized for code and similar line-based text file" +msgstr "" + +msgid "It even pulls software to the plain text direction, e.g.:" +msgstr "" + +msgid "delivery-templates" +msgstr "" + +msgid "`common-core.protocols.config`" +msgstr "" + +msgid "Why not exploit that more?" +msgstr "" + +msgid "Ditching of web applications" +msgstr "" + +msgid "The architecture of web apps remains fundamentally server-centric" +msgstr "" + +msgid "" +"Disagree. Contrast [PouchDB](https://pouchdb.com/) with Android [Instant " +"Apps](https://developer.android.com/topic/google-play-instant)" +msgstr "" + +msgid "???" +msgstr "" + +msgid "Talk on dynamic content" +msgstr "" + +msgid "Costs are underrated" +msgstr "" + +msgid "backups" +msgstr "" + +msgid "maintenance" +msgstr "" + +msgid "Example: blog vs vlog" +msgstr "" + +msgid "Real-time collaboration a bit overrated" +msgstr "" + +msgid "" +"It is only possible on the presence of reliable, medium-quality network " +"connection" +msgstr "" + +msgid "X also works when inside an elevator, subway or plane!" +msgstr "" + +msgid "On CRDTs and developer experience" +msgstr "" + +msgid "" +"For an app developer, how does the use of a CRDT-based data layer compare to" +" existing storage layers like a SQL database, a filesystem, or CoreData? Is " +"a distributed system harder to write software for?" +msgstr "" + +msgid "Yes." +msgstr "" + +msgid "" +"See \"[A Note on Distributed " +"Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\"" +msgstr "" + +msgid "Conclusion" +msgstr "" + +msgid "Why this is a \"paper I love\": it took offline-first and ran with it." +msgstr "" + +msgid "But a pinch of CRDT won't make the world local-first." +msgstr "" + +msgid "The tricky part is the end of the sentence: \"**in spite of the Cloud**\"." +msgstr "" + +msgid "Thank you!" +msgstr "" + +msgid "References:" +msgstr "" + +msgid "these slides: [{{ site.tld }}/slides.html]({% link slides.md %})" +msgstr "" + +msgid "" +"[prose version of this presentation]({% link _articles/2020-11-14-local-" +"first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md %})" +msgstr "" + +msgid "" +"\"[Local-First Software: You Own Your Data, in spite of the " +"Cloud](https://martin.kleppmann.com/papers/local-first.pdf)\", by M. " +"Kleppmann, A. Wiggins, P. Van Hardenberg and M. F. McGranaghan" +msgstr "" + +msgid "" +"[The Morning Paper](https://blog.acolyer.org/2019/11/20/local-first-" +"software/) article" +msgstr "" + +msgid "" +"\"[A Note on Distributed " +"Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\"," +" by J. Waldo, G. Wyant, A. Wollrath and S Kendall" +msgstr "" diff --git a/locale/pt/LC_MESSAGES/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.po b/locale/pt/LC_MESSAGES/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.po new file mode 100644 index 0000000..ade1529 --- /dev/null +++ b/locale/pt/LC_MESSAGES/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.po @@ -0,0 +1,497 @@ +# +msgid "" +msgstr "" + +msgid "" +"title: \"Local-First Software: You Own Your Data, in spite of the Cloud - " +"article review\"" +msgstr "" + +msgid "date: 2020-11-14" +msgstr "" + +msgid "layout: post" +msgstr "" + +msgid "lang: en" +msgstr "" + +msgid "" +"ref: local-first-software-you-own-your-data-in-spite-of-the-cloud-article-" +"review" +msgstr "" + +msgid "eu_categories: presentation,article review" +msgstr "" + +msgid "" +"*This article is derived from a [presentation][presentation] given at a " +"Papers We Love meetup on the same subject.*" +msgstr "" + +msgid "" +"This is a review of the article \"[Local-First Software: You Own Your Data, " +"in spite of the Cloud][article-pdf]\", by M. Kleppmann, A. Wiggins, P. Van " +"Hardenberg and M. F. McGranaghan." +msgstr "" + +msgid "Offline-first, local-first" +msgstr "" + +msgid "" +"The \"local-first\" term they use isn't new, and I have used it myself in " +"the past to refer to this types of application, where the data lives " +"primarily on the client, and there are conflict resolution algorithms that " +"reconcile data created on different instances." +msgstr "" + +msgid "" +"Sometimes I see confusion with this idea and \"client-side\", \"offline-" +"friendly\", \"syncable\", etc. I have myself used this terms, also." +msgstr "" + +msgid "" +"There exists, however, already the \"offline-first\" term, which conveys " +"almost all of that meaning. In my view, \"local-first\" doesn't extend " +"\"offline-first\" in any aspect, rather it gives a well-defined meaning to " +"it instead. I could say that \"local-first\" is just \"offline-first\", but " +"with 7 well-defined ideals instead of community best practices." +msgstr "" + +msgid "" +"[presentation]: {% link _slides/2020-11-14-on-local-first-beyond-the-crdt-" +"silver-bullet.slides %} [article-pdf]: " +"https://martin.kleppmann.com/papers/local-first.pdf" +msgstr "" + +msgid "Software licenses" +msgstr "" + +msgid "" +"On a footnote of the 7th ideal (\"You Retain Ultimate Ownership and " +"Control\"), the authors say:" +msgstr "" + +msgid "" +"In our opinion, maintaining control and ownership of data does not mean that" +" the software must necessarily be open source. (...) as long as it does not " +"artificially restrict what users can do with their files." +msgstr "" + +msgid "" +"#!/bin/sh\n" +"\n" +"TODAY=$(date +%s)\n" +"LICENSE_EXPIRATION=$(date -d 2020-11-15 +%s)\n" +"\n" +"if [ $TODAY -ge $LICENSE_EXPIRATION ]; then\n" +" echo 'License expired!'\n" +" exit 1\n" +"fi\n" +"\n" +"echo $((2 + 2))\n" +msgstr "" + +msgid "Now when using this very useful program:" +msgstr "" + +msgid "" +"# today\n" +"$ ./useful-adder.sh\n" +"4\n" +"# tomorrow\n" +"$ ./useful-adder.sh\n" +"License expired!\n" +msgstr "" + +msgid "" +"This is obviously an intentional restriction, and it goes against the 5th " +"ideal (\"The Long Now\"). This software would only be useful as long as the " +"embedded license expiration allowed. Sure you could change the clock on the " +"computer, but there are many other ways that this type of intentional " +"restriction is in conflict with that ideal." +msgstr "" + +msgid "" +"However, what about unintentional restrictions? What if a software had an " +"equal or similar restriction, and stopped working after days pass? Or what " +"if the programmer added a constant to make the development simpler, and this" +" led to unintentionally restricting the user?" +msgstr "" + +msgid "" +"# today\n" +"$ useful-program\n" +"# ...useful output...\n" +"\n" +"# tomorrow, with more data\n" +"$ useful-program\n" +"ERROR: Panic! Stack overflow!\n" +msgstr "" + +msgid "" +"The point is: if the software isn't free/libre, \"The Long Now\" isn't " +"achievable without a lot of wishful thinking. Maybe the authors were trying " +"to be more friendly towards business who don't like FOSS, but in doing so " +"they've proposed a contradiction by reconciling \"The Long Now\" with " +"proprietary software." +msgstr "" + +msgid "" +"It isn't the same as saying that any free/libre software achieves that " +"ideal, either. The license can still be free, but the source code can become" +" unavailable due to cloud rot. Or maybe the build is undocumented, or the " +"build tools had specific configuration that one has to guess. A piece of " +"free/libre software can still fail to achieve \"The Long Now\". Being free " +"doesn't guarantee it, just makes it possible." +msgstr "" + +msgid "" +"An open specification could serve as a blueprint to other implementations, " +"making the data format more friendly to reverse-engineering. But the re-" +"implementation still has to exist, at which point the original software " +"failed to achieve \"The Long Now\"." +msgstr "" + +msgid "It is less bad, but still not quite there yet." +msgstr "" + +msgid "Denial of existing solutions" +msgstr "" + +msgid "" +"When describing \"Existing Data Storage and Sharing Models\", on a " +"footnote[^devil] the authors say:" +msgstr "" + +msgid "" +"[^devil]: This is the second aspect that I'm picking on the article from a " +"footnote. I guess the devil really is on the details." +msgstr "" + +msgid "" +"In principle it is possible to collaborate without a repository service, " +"e.g. by sending patch files by email, but the majority of Git users rely on " +"GitHub." +msgstr "" + +msgid "" +"The authors go to a great length to talk about usability of cloud apps, and " +"even point to research they've done on it, but they've missed learning more " +"from local-first solutions that already exist." +msgstr "" + +msgid "" +"Say the automerge CRDT proves to be even more useful than what everybody " +"imagined. Say someone builds a local-first repository service using it. How " +"will it change anything of the Git/GitHub model? What is different about it " +"that prevents people in the future writing a paper saying:" +msgstr "" + +msgid "" +"In principle it is possible to collaborate without a repository service, " +"e.g. by using automerge and platform X, but the majority of Git users rely " +"on GitHub." +msgstr "" + +msgid "How is this any better?" +msgstr "" + +msgid "" +"If it is already [possible](https://drewdevault.com/2018/07/23/Git-is-" +"already-distributed.html) to have a local-first development workflow, why " +"don't people use it? Is it just fashion, or there's a fundamental problem " +"with it? If so, what is it, and how to avoid it?" +msgstr "" + +msgid "" +"If sending patches by emails is perfectly possible but out of fashion, why " +"even talk about Git/GitHub? Isn't this a problem that people are putting " +"themselves in? How can CRDTs possibly prevent people from doing that?" +msgstr "" + +msgid "" +"My impression is that the authors envision a better future, where " +"development is fully decentralized unlike today, and somehow CRDTs will make" +" that happen. If more people think this way, \"CRDT\" is next in line to the" +" buzzword list that solves everything, like \"containers\", \"blockchain\" " +"or \"machine learning\"." +msgstr "" + +msgid "" +"Rather than picturing an imaginary service that could be described like " +"\"GitHub+CRDTs\" and people would adopt it, I'd rather better understand why" +" people don't do it already, since Git is built to work like that." +msgstr "" + +msgid "Ditching of web applications" +msgstr "" + +msgid "" +"The authors put web application in a worse position for building local-first" +" application, claiming that:" +msgstr "" + +msgid "" +"(...) the architecture of web apps remains fundamentally server-centric. " +"Offline support is an afterthought in most web apps, and the result is " +"accordingly fragile." +msgstr "" + +msgid "Well, I disagree." +msgstr "" + +msgid "" +"The problem isn't inherit to the web platform, but instead how people use " +"it." +msgstr "" + +msgid "" +"I have myself built offline-first applications, leveraging IndexedDB, App " +"Cache, *etc*. I wanted to build an offline-first application on the web, and" +" so I did." +msgstr "" + +msgid "" +"In fact, many people choose [PouchDB](https://pouchdb.com/) *because* of " +"that, since it is a good tool for offline-first web applications. The " +"problem isn't really the technology, but how much people want their " +"application to be local-first." +msgstr "" + +msgid "" +"Contrast it with Android [Instant " +"Apps](https://developer.android.com/topic/google-play-instant), where " +"applications are sent to the phone in small parts. Since this requires an " +"internet connection to move from a part of the app bundle to another, a " +"subset of the app isn't local-first, despite being an app." +msgstr "" + +msgid "" +"The point isn't the technology, but how people are using it. Local-first web" +" applications are perfectly possible, just like non-local-first native " +"applications are possible." +msgstr "" + +msgid "Costs are underrated" +msgstr "" + +msgid "" +"I think the costs of \"old-fashioned apps\" over \"cloud apps\" are " +"underrated, mainly regarding storage, and that this costs can vary a lot by " +"application." +msgstr "" + +msgid "" +"Say a person writes online articles for their personal website, and puts " +"everything into Git. Since there isn't supposed to be any collaboration, all" +" of the relevant ideals of local-first are achieved." +msgstr "" + +msgid "" +"Now another person creates videos instead of articles. They could try " +"keeping everything local, but after some time the storage usage fills the " +"entire disk. This person's local-first setup would be much more complex, and" +" would cost much more on maintenance, backup and storage." +msgstr "" + +msgid "" +"Even though both have similar needs, a local-first video repository is much " +"more demanding. So the local-first thinking here isn't \"just keep " +"everything local\", but \"how much time and money am I willing to spend to " +"keep everything local\"." +msgstr "" + +msgid "" +"The convenience of \"cloud apps\" becomes so attractive that many don't even" +" have a local copy of their videos, and rely exclusively on service " +"providers to maintain, backup and store their content." +msgstr "" + +msgid "" +"The dial measuring \"cloud apps\" and \"old-fashioned apps\" needs to be " +"specific to use-cases." +msgstr "" + +msgid "Real-time collaboration is optional" +msgstr "" + +msgid "" +"If I were the one making the list of ideals, I wouldn't focus so much on " +"real-time collaboration." +msgstr "" + +msgid "" +"Even though seamless collaboration is desired, it being real-time depends on" +" the network being available for that. But ideal 3 states that \"The Network" +" is Optional\", so real-time collaboration is also optional." +msgstr "" + +msgid "" +"The fundamentals of a local-first system should enable real-time " +"collaboration when network is available, but shouldn't focus on it." +msgstr "" + +msgid "" +"On many places when discussing applications being offline, it is common for " +"me to find people saying that their application works \"even on a plane, " +"subway or elevator\". That is a reflection of when said developers have to " +"deal with networks being unavailable." +msgstr "" + +msgid "" +"When discussing \"working offline\", I'd rather keep this type of person in " +"mind, then the subset of people who are offline when on the elevator will " +"naturally be included." +msgstr "" + +msgid "On CRDTs and developer experience" +msgstr "" + +msgid "" +"When discussing developer experience, the authors bring up some questions to" +" be answered further, like:" +msgstr "" + +msgid "" +"For an app developer, how does the use of a CRDT-based data layer compare to" +" existing storage layers like a SQL database, a filesystem, or CoreData? Is " +"a distributed system harder to write software for?" +msgstr "" + +msgid "That is an easy one: yes." +msgstr "" + +msgid "" +"A distributed system *is* harder to write software for, being a distributed " +"system." +msgstr "" + +msgid "Conclusion" +msgstr "" + +msgid "" +"I liked a lot the article, as it took the \"offline-first\" philosophy and " +"ran with it." +msgstr "" + +msgid "" +"But I think the authors' view of adding CRDTs and things becoming local-" +"first is a bit too magical." +msgstr "" + +msgid "" +"It is a step forward, and given the number of times I've seen the paper " +"shared around I think there's a chance people will prefer saying \"local-" +"first\" in *lieu* of \"offline-first\" from now on." +msgstr "" + +msgid "" +"They give examples of artificial restrictions, like this artificial " +"restriction I've come up with:" +msgstr "" + +msgid "" +"Just as easily as I can come up with ways to intentionally restrict users, I" +" can do the same for unintentionally restrictions. A program can stop " +"working for a variety of reasons." +msgstr "" + +msgid "" +"If it stops working due do, say, data growth, what are the options? " +"Reverting to an earlier backup, and making it read-only? That isn't really a" +" \"Long Now\", but rather a \"Long Now as long as the software keeps working" +" as expected\"." +msgstr "" + +msgid "" +"A colleague has challenged my view, arguing that the software doesn't really" +" need to be free, as long as there is an specification of the file format. " +"This way if the software stops working, the format can still be processed by" +" other programs. But this doesn't apply in practice: if you have a document " +"that you write to, and software stops working, you still want to write to " +"the document. An external tool that navigates the content and shows it to " +"you won't allow you to keep writing, and when it does that tool is now " +"starting to re-implement the software." +msgstr "" + +msgid "" +"But this leaves out a big chunk of the world where internet connection is " +"intermittent, or only works every other day or only once a week, or stops " +"working when it rains, *etc*. For this audience, living without network " +"connectivity isn't such a discrete moment in time, but part of every day " +"life. I like the fact that the authors acknowledge that." +msgstr "" + +msgid "" +"Adding a large layer of data structures and algorithms will make it more " +"complex to write software for, naturally. And if trying to make this layer " +"transparent to the programmer, so they can pretend that layer doesn't exist " +"is a bad idea, as RPC frameworks have tried, and failed." +msgstr "" + +msgid "" +"See \"[A Note on Distributed " +"Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\"" +" for a critique on RPC frameworks trying to make the network invisible, " +"which I think also applies in equivalence for making the CRDTs layer " +"invisible." +msgstr "" + +msgid "" +"This particular area is one that I have large interest on, and I wish to see" +" more being done on the \"local-first\" space." +msgstr "" + +#~ msgid "They give examples of artificial restrictions, like this one:" +#~ msgstr "" + +#~ msgid "" +#~ "Just as easily as I can come up with ways to intentionally restrict users, " +#~ "just as easily I can do the same for unintentionally restricting users. A " +#~ "program can stop working for a variety of reasons." +#~ msgstr "" + +#~ msgid "" +#~ "If it stops working due do data growth, what are the options? Reverting to " +#~ "an earlier backup, and making it read-only? That isn't really a \"Long " +#~ "Now\", but rather a \"Long Now as long as the software keeps working as " +#~ "expected\"." +#~ msgstr "" + +#~ msgid "" +#~ "A colleague has challenged my view, arguing that the software doesn't really" +#~ " need to be free, as long as there is an specification of the file format. " +#~ "This way is the software stops working, the format can still be processed by" +#~ " other programs. But this doesn't apply in practice: if you have a document " +#~ "that you write to, and software stops working, you still want to write to " +#~ "the document. An external tool that navigates the content and shows it to " +#~ "you won't allow you to keep writing, and when it does that tool is now " +#~ "starting to re-implement the software." +#~ msgstr "" + +#~ msgid "" +#~ "But this leaves out a big chunk of the world where internet connection is " +#~ "intermittent, or only work every other day or only once a week, or stops " +#~ "working when it rains, *etc*. For this audience, living without network " +#~ "connectivity isn't such a discrete moment in time, but part of every day " +#~ "life. I like the fact that the authors acknowledge that." +#~ msgstr "" + +#~ msgid "" +#~ "Adding a large layer of data structures and algorithms will make it more " +#~ "complex to write software for, naturally. And if trying to make this layer " +#~ "transparent to the programmer, so they can pretend that layer doesn't exist " +#~ "is a bad idea, as RPC frameworks have tried, and failed. See \"[A Note on " +#~ "Distributed " +#~ "Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\"" +#~ " for a critique on RPC frameworks trying to make the network invisible, " +#~ "which I think also applies in equivalence for making the CRDTs layer " +#~ "invisible." +#~ msgstr "" + +#~ msgid "" +#~ "It is a step forward, and given the number of times I've seen the paper " +#~ "shared around I think there's a chance people will prefer saying \"local-" +#~ "first\" in lieu of \"offline-first\" from now on." +#~ msgstr "" diff --git a/locale/pt/LC_MESSAGES/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides.po b/locale/pt/LC_MESSAGES/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides.po new file mode 100644 index 0000000..7674704 --- /dev/null +++ b/locale/pt/LC_MESSAGES/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides.po @@ -0,0 +1,322 @@ +# +msgid "" +msgstr "" + +msgid "title: 'On \"local-first\": beyond the CRDT silver bullet'" +msgstr "" + +msgid "date: 2020-11-14" +msgstr "" + +msgid "layout: slides" +msgstr "" + +msgid "lang: en" +msgstr "" + +msgid "ref: on-local-first-beyond-the-crdt-silver-bullet" +msgstr "" + +msgid "On local-first" +msgstr "" + +msgid "Beyond the CRDT silver bullet" +msgstr "" + +msgid "Part 1" +msgstr "" + +msgid "Exposition" +msgstr "" + +msgid "\"cloud apps\" vs \"old-fashioned apps\"" +msgstr "" + +msgid "Target" +msgstr "" + +msgid "documents" +msgstr "" + +msgid "files" +msgstr "" + +msgid "personal data repositories" +msgstr "" + +msgid "" +"Not: banking services, e-commerce, social networking, ride-sharing, *etc*." +msgstr "" + +msgid "7 Ideals for local-first software" +msgstr "" + +msgid "1 - No Spinners: Your Work at Your Fingertips" +msgstr "" + +msgid "2 - Your Work Is Not Trapped on One Device" +msgstr "" + +msgid "3 - The Network Is Optional" +msgstr "" + +msgid "4 - Seamless Collaboration with Your Colleagues" +msgstr "" + +msgid "5 - The Long Now" +msgstr "" + +msgid "6 - Security and Privacy by Default" +msgstr "" + +msgid "7 - You Retain Ultimate Ownership and Control" +msgstr "" + +msgid "Towards a Better Future" +msgstr "" + +msgid "" +"CRDTs (Conflict-free Replicated Data Types) as a Foundational Technology" +msgstr "" + +msgid "Use case" +msgstr "" + +msgid "" +"# in node A and node B\n" +"s = \"Hello, World\"\n" +"\n" +"# in node A\n" +"s = \"Hello, Alice\"\n" +"\n" +"# in node B\n" +"s = \"Hello, Bob\"\n" +msgstr "" + +msgid "How to reconcile those?" +msgstr "" + +msgid "`Hello, ABloibce`" +msgstr "" + +msgid "`Hello, AliceBob`" +msgstr "" + +msgid "`Hello, BobAlice`" +msgstr "" + +msgid "`Hello, Alice`" +msgstr "" + +msgid "`Hello, Bob`" +msgstr "" + +msgid "Existing CRDTs differ:" +msgstr "" + +msgid "performance" +msgstr "" + +msgid "storage" +msgstr "" + +msgid "compression" +msgstr "" + +msgid "metadata overhead" +msgstr "" + +msgid "Hint towards the \"automerge\" CRDT" +msgstr "" + +msgid "*show comparison table, page 9*" +msgstr "" + +msgid "Part 2" +msgstr "" + +msgid "Critique" +msgstr "" + +msgid "Software license" +msgstr "" + +msgid "" +"In our opinion, maintaining control and ownership of data does not mean that" +" the software must necessarily be open source." +msgstr "" + +msgid "Example 1 - intentional restriction" +msgstr "" + +msgid "" +"#!/bin/sh\n" +"\n" +"TODAY=$(date +%s)\n" +"LICENSE_EXPIRATION=$(date -d 2020-10-27 +%s)\n" +"\n" +"if [ $TODAY -ge $LICENSE_EXPIRATION ]; then\n" +" echo 'License expired!'\n" +" exit 1\n" +"fi\n" +"\n" +"echo $((2 + 2))\n" +msgstr "" + +msgid "" +"# today\n" +"$ ./useful-adder.sh\n" +"4\n" +"# tomorrow\n" +"$ ./useful-adder.sh\n" +"License expired!\n" +msgstr "" + +msgid "Example 2 - unintentional restriction" +msgstr "" + +msgid "" +"# today\n" +"$ useful-program\n" +"# ...useful output...\n" +"\n" +"# tomorrow, with more data\n" +"$ useful-program\n" +"ERROR: Panic! Stack overflow!\n" +msgstr "" + +msgid "local-first **requires** free/libre software" +msgstr "" + +msgid "Otherwise \"The Long Now\" (ideal nº5) is lost" +msgstr "" + +msgid "Denial of existing solutions" +msgstr "" + +msgid "" +"In principle it is possible to collaborate without a repository service, " +"e.g. by sending patch files by email, but the majority of Git users rely on " +"GitHub." +msgstr "" + +msgid "Solution: either GitHub+CRDTs or `git` **`send-email`**" +msgstr "" + +msgid "Plain text formats" +msgstr "" + +msgid "Git is highly optimized for code and similar line-based text file" +msgstr "" + +msgid "It even pulls software to the plain text direction, e.g.:" +msgstr "" + +msgid "delivery-templates" +msgstr "" + +msgid "`common-core.protocols.config`" +msgstr "" + +msgid "Why not exploit that more?" +msgstr "" + +msgid "Ditching of web applications" +msgstr "" + +msgid "The architecture of web apps remains fundamentally server-centric" +msgstr "" + +msgid "" +"Disagree. Contrast [PouchDB](https://pouchdb.com/) with Android [Instant " +"Apps](https://developer.android.com/topic/google-play-instant)" +msgstr "" + +msgid "???" +msgstr "" + +msgid "Talk on dynamic content" +msgstr "" + +msgid "Costs are underrated" +msgstr "" + +msgid "backups" +msgstr "" + +msgid "maintenance" +msgstr "" + +msgid "Example: blog vs vlog" +msgstr "" + +msgid "Real-time collaboration a bit overrated" +msgstr "" + +msgid "" +"It is only possible on the presence of reliable, medium-quality network " +"connection" +msgstr "" + +msgid "X also works when inside an elevator, subway or plane!" +msgstr "" + +msgid "On CRDTs and developer experience" +msgstr "" + +msgid "" +"For an app developer, how does the use of a CRDT-based data layer compare to" +" existing storage layers like a SQL database, a filesystem, or CoreData? Is " +"a distributed system harder to write software for?" +msgstr "" + +msgid "Yes." +msgstr "" + +msgid "" +"See \"[A Note on Distributed " +"Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\"" +msgstr "" + +msgid "Conclusion" +msgstr "" + +msgid "Why this is a \"paper I love\": it took offline-first and ran with it." +msgstr "" + +msgid "But a pinch of CRDT won't make the world local-first." +msgstr "" + +msgid "The tricky part is the end of the sentence: \"**in spite of the Cloud**\"." +msgstr "" + +msgid "Thank you!" +msgstr "" + +msgid "References:" +msgstr "" + +msgid "these slides: [{{ site.tld }}/slides.html]({% link slides.md %})" +msgstr "" + +msgid "" +"[prose version of this presentation]({% link _articles/2020-11-14-local-" +"first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md %})" +msgstr "" + +msgid "" +"\"[Local-First Software: You Own Your Data, in spite of the " +"Cloud](https://martin.kleppmann.com/papers/local-first.pdf)\", by M. " +"Kleppmann, A. Wiggins, P. Van Hardenberg and M. F. McGranaghan" +msgstr "" + +msgid "" +"[The Morning Paper](https://blog.acolyer.org/2019/11/20/local-first-" +"software/) article" +msgstr "" + +msgid "" +"\"[A Note on Distributed " +"Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\"," +" by J. Waldo, G. Wyant, A. Wollrath and S Kendall" +msgstr "" diff --git a/scripts/spelling/en.txt b/scripts/spelling/en.txt index 98a0351..939e182 100644 --- a/scripts/spelling/en.txt +++ b/scripts/spelling/en.txt @@ -9,8 +9,10 @@ backend balancer barcode behaviour +centric chargeback combinators +config couldn cronjobs culting diff --git a/scripts/spelling/international.txt b/scripts/spelling/international.txt index dc9b90e..8b6488a 100644 --- a/scripts/spelling/international.txt +++ b/scripts/spelling/international.txt @@ -7,8 +7,10 @@ 500GB 81F90EC3CD356060 8GB +ABloibce AGPLv AGPLv3 +AliceBob André Anna Atom @@ -19,11 +21,15 @@ BY BY-SA Binet Bitbucket +BobAlice CDN CI CLI +CRDT +CRDTs Cantrill Clojure +CoreData CouchDB DIY DVCS @@ -31,6 +37,7 @@ Datomic EuAndreh F FFI +FOSS FP FTS Fastmail @@ -46,6 +53,7 @@ HN HTML HTTPS Halloway +Hardenberg Haskell Henney Hodgson @@ -57,6 +65,7 @@ JS JSON Joyent Kevlin +Kleppmann L1 LSM LTS @@ -66,6 +75,7 @@ LilyPond LiquidHaskell Mailutils Matroska +McGranaghan Mentat Merkle NPM @@ -84,6 +94,7 @@ PoC PouchDB RDF README +RPC RPN RSS Raku @@ -108,11 +119,15 @@ UI URL VPN WebAssembly +Wollrath +Wyant Yandex YouTube Zig apk +automerge bindgen +blockchain boneco br brainer @@ -136,9 +151,11 @@ euandre euandreh eval ffi +fi fr frontend gcrypt +ge gt guix guixbuild @@ -178,6 +195,7 @@ org pastebin pastebins plaintext +pouchdb progn pt rollout @@ -192,6 +210,7 @@ só touchpad txt v8 +vlog www xp xyz -- cgit v1.2.3