aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorElena ``of Valhalla'' Grandi <valhalla@trueelena.org>2016-08-24 18:20:22 +0200
committerElena ``of Valhalla'' Grandi <valhalla@trueelena.org>2016-08-24 18:20:22 +0200
commit0da23a79c8a99f32edf339469bf2895303a16736 (patch)
treeb51c130ae8818e15d16569f899e15ed552a7bf85
parentbc24489c2c53bb96f66b19c9a6d4107dd644f87b (diff)
fixes to subtitles
-rw-r--r--subtitles.rst31
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.