fixes to subtitles

1 files changed, 17 insertions, 14 deletions

diff --git a/subtitles.rst b/subtitles.rst
index 9c62ed7..a9d32e7 100644
--- a/subtitles.rst
+++ b/subtitles.rst
@@ -1,8 +1,8 @@
 When I was young, my parents taught me not to accept candy from strangers,
 unless they were present and approved of it, because there was a small risk
 of very bad things happening.
-It was of course a simplicistic rule, but it had to be easy enough to follow
-for somebody who wasn't proficient (yet) in the subleties of social
+It was of course a simplistic rule, but it had to be easy enough to follow
+for somebody who wasn't proficient (yet) in the subtleties of social
 interactions.
 
 One of the reasons why it worked well was that following it wasn't a big
@@ -12,7 +12,7 @@ been a great one, the ones I could have at home were also good.
 
 Contrary to candy, offers of gratis software from random strangers are quite
 common: from suspicious looking websites to legit and professional looking
-ones, to platforms that are explicitely designed to allow developers to
+ones, to platforms that are explicitly designed to allow developers to
 publish their own software with little or no checks.
 
 Just like candy, there is also a source of trusted software in the Linux
@@ -38,7 +38,7 @@ agree is a good thing.
 
 What I however believe is that getting code from such sources and using it
 *without carefully checking it* is even more risky than accepting candy from a
-random stranger on the street in an unfamiliar neighborhood.
+random stranger on the street in an unfamiliar neighbourhood.
 
 The risk aren't trivial: while you probably won't be taken as an hostage for
 ransom, your data could be, or your devices and the ones who run your
@@ -52,14 +52,14 @@ compatibility and what can be expected in case an old version is found to
 have security issues.
 
 The very fact that everybody can publish anything on such platforms is
-both their biggest strenght and their main source of vulnerability:
+both their biggest strength and their main source of vulnerability:
 while most of the people who publish their libraries do so with good
 intentions, attacks have been described and publicly tested, such as the
-fun typosquatting_ one (`archived url`_) that published harmless
+fun `typo-squatting`_ one (`archived URL`_) that published harmless
 malicious code under common typos for famous libraries.
 
-.. _typosquatting: http://incolumitas.com/2016/06/08/typosquatting-package-managers/
-.. _`archived url`: http://web.archive.org/web/20160801161807/http://incolumitas.com/2016/06/08/typosquatting-package-managers/
+.. _`typo-squatting`: http://incolumitas.com/2016/06/08/typosquatting-package-managers/
+.. _`archived URL`: http://web.archive.org/web/20160801161807/http://incolumitas.com/2016/06/08/typosquatting-package-managers/
 
 Contrast this with Debian, where everybody can contribute, but before
 they are allowed full unsupervised access to the archive they have to
@@ -83,7 +83,7 @@ Additionally, package maintainers don't work in isolation: a growing
 number of packages are being maintained by a team of people, and most
 importantly there are aspects that involve potentially the whole
 community, from the fact that new packages that enter the distribution
-are publicy announced on a mailing list to the various distribution-wide
+are publicity announced on a mailing list to the various distribution-wide
 QA efforts.
 
 Going back to the language specific distribution platforms, sometimes
@@ -108,21 +108,24 @@ in its constitution_.
 .. _`social contract`: https://www.debian.org/social_contract
 .. _constitution: https://www.debian.org/devel/constitution
 
-Additionally, 
+Additionally, the long history of the distribution model means that many
+issues have already been met, the errors have already been done, and
+there are established technical procedures to deal with them in a better
+way.
 
-So, shouln't we use language specific distribution platforms at all?
+So, shouldn't we use language specific distribution platforms at all?
 No! As developers we aren't children, we are adults who have the skills
 to distinguish between safe and unsafe libraries just as well as the
 average distribution maintainer can do.
 What I believe we should do is stop treating them as a safe source that
-can be used blindly and reserve that status to actual trustable sources
+can be used blindly and reserve that status to actual trustful sources
 like Debian, falling back to the language specific platforms only when
 strictly needed, and in that case:
 
 * actually check carefully what we are using, both by reading the code
-  and by analyzing the developement and community practices of the
+  and by analysing the development and community practices of the
   authors;
-* if possible, share that work by becoming ourself maintainers of that
+* if possible, share that work by becoming ourselves maintainers of that
   library in our favourite distribution, to prevent duplication of
   effort and to give back to the community whose work we get advantage
   from.