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.po | 497 +++++++++++++++++++++ 1 file changed, 497 insertions(+) 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 (limited to 'locale/eo/LC_MESSAGES/_articles') 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 "" -- cgit v1.2.3