diff options
Diffstat (limited to '')
| -rw-r--r-- | _articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md (renamed from _articles/2020-10-26-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md) | 51 |
1 files changed, 27 insertions, 24 deletions
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-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md index 409dfaf..1a41c0c 100644 --- a/_articles/2020-10-26-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 @@ -12,8 +12,6 @@ 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 @@ -40,10 +38,10 @@ 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. +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 %} +[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 @@ -55,7 +53,8 @@ the authors say: > 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: +They give examples of artificial restrictions, like this artificial restriction +I've come up with: ```bash #!/bin/sh @@ -103,12 +102,12 @@ $ 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. +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 data growth, what are the options? Reverting to an -earlier backup, and making it read-only? That isn't really a "Long Now", but +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 @@ -125,16 +124,16 @@ 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 +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 reimplement the +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 -reimplementation still has to exist, at which point the original software failed +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. @@ -172,10 +171,10 @@ 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? +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 CDRTs will make that happen. If +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". @@ -205,7 +204,7 @@ 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 +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. @@ -219,7 +218,7 @@ applications are possible. ### Costs are underrated -I think the costs of "old-fashined apps" over "cloud apps" 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 @@ -229,7 +228,7 @@ 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. +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", @@ -239,7 +238,7 @@ 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 +The dial measuring "cloud apps" and "old-fashioned apps" needs to be specific to use-cases. ### Real-time collaboration is optional @@ -259,8 +258,8 @@ 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 +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. @@ -286,8 +285,9 @@ 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 +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. @@ -301,3 +301,6 @@ 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. |