|
From: | Alexandre Garreau |
Subject: | Re: Does service lookup by name work on Windows now? |
Date: | Mon, 28 Jan 2019 12:03:25 +0100 |
User-agent: | Gnus (5.13), GNU Emacs 25.1.1 (i686-pc-linux-gnu, GTK+ Version 3.22.11) of 2017-09-15, modified by Debian |
So to make the thing not fully negative, would it be useful to recall that sometimes we make free software work on Windows so that to offer a taste of freedom, and state in this text that in when doing so, we prefer to keep this software working on older versions?
Maybe something could be added on the fact that computers should be owned by users and then it should be their choice to get new (anti-)features or not (and to choose between stability and flexibility)… be it, preferably, with “security updates” backported on old versions, as it is only possible with free software, and as “some GNU/Linux distributions” (so not to cite Debian) already do.
Then recalling it is nowadays commonplace for proprietary software to force upgrades (often with multiple anti-features), that this is an anti-feature, that this implies an universal backdoor, and that is a good reason to go GNU/Linux instead of Windows 8/10, so you might hook there the anti-windows-8/10 campaign.
Also something, maybe too much but still: forced upgrades are often described by software editors as a “feature” because it allows to correct “bugs” or “security holes” that are client-side: for instance, a glitch in a game that allow for a user to cheat in their own interest, or more commonly they notice spam, or harassement, begins to appear in their “application”, so they “fortunately” and happily update so to allow censorship on the clients that cause the problem.
So instead of having some clients capable to block other users, or to detect cheat (which may be seen as a feature), they make the application sending the spam unable to work or send anything (while this is still technically possible if they knew the protocol), or the game unable to cheat: in each case, the (anti-)“feature” is made so that to go against the will of the user that gets the update. This is also a wrong way of approaching security, as it keeps protocols and receiver-clients (rather than whole clients or their emitting part) dumb, insecure and inferior. A thing that is impossible with free software (you just download the old version, or change the software, and exploit the protocol again: so you have to fix it reader-side, or protocol-side).
[Prev in Thread] | Current Thread | [Next in Thread] |