From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2011-November/009895.html | 189 +++++++++++++++++++++++++++ 1 file changed, 189 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-November/009895.html (limited to 'zarb-ml/mageia-dev/2011-November/009895.html') diff --git a/zarb-ml/mageia-dev/2011-November/009895.html b/zarb-ml/mageia-dev/2011-November/009895.html new file mode 100644 index 000000000..8c48a4cee --- /dev/null +++ b/zarb-ml/mageia-dev/2011-November/009895.html @@ -0,0 +1,189 @@ + + + + [Mageia-dev] Teamviewer and X86_64 build . . . + + + + + + + + + +

[Mageia-dev] Teamviewer and X86_64 build . . .

+ Michael Scherer + misc at zarb.org +
+ Mon Nov 28 14:40:34 CET 2011 +

+
+ +
Le lundi 28 novembre 2011 à 12:09 +0100, Kamil Rytarowski a écrit :
+> On 28.11.2011 11:32, Guillaume Rousse wrote:
+> > Le 28/11/2011 11:28, Kamil Rytarowski a écrit :
+> >> There were a few requests for TeamViewer in my local Mageia site - I
+> >> suggest to add it to our repositories (probably as tainted and as a
+> >> downloading script).
+
+That's non-free, not tainted. 
+
+> > They are better ways to contribute to the distribution than helping 
+> > 'poor little users' to install crappy proprietary software. Such as 
+> > writing documentation about dependency management, for instance.
+> >
+> I wouldn't like to follow the OpenBSD way...
+
+Why ?
+
+They managed to be a highly recognized system, seen as one of the best
+in his category, and was able to be developed since 1994. 
+
+>  There is software like 
+> TrueCrypt, Skype, TeamViewer that many users need. And there is no harm 
+> to add it to repositories.
+
+I would like to remind that our focus is doing free software. And it is
+not "becoming a dumping ground for proprietary software". 
+
+There is several pragmatic reasons for that and, there is also some long
+term harm by shipping more and more proprietary software like : 
+- we cannot support them ( no source code, most of the time, no proper
+bug report tools, anything ), with the implied consequence of "we cannot
+trust them".
+
+- it also make the distinction between application we trust and buggy
+stuff that we don't ( skype, flash ) harder to see. We can no longer say
+to people "you can trust us, everything in our repository is checked and
+supported", since this is not the case. So I personally no longer say to
+people to trust us because of that.
+
+- Most if not all proprietary softwares do not permit proper
+cooperation, which mean that we cannot plan much around it. So we cannot
+place them as proeminent features, unless we want to later risk not
+fullfilling our promises ( and I will not talk about how it goes against
+cooperation values ). This also place in a uncomfortable position since
+we are just treated as 2nd class citizen.
+
+- such software can have a impact on migration to new softwares, and may
+requires us to keep old compatibility version, thus adding more QA and
+more complexity ( again, I can think of skype, who took a long time to
+support pulseaudio, thus forcing more hack to integrate, or the whole
+32b/64bits system who was solely needed just for stuff like flash or
+wine ). 
+
+- some softwares like nvidia or flash are notoriously buggy, thus making
+our distribution look bad when it crash, make people lose time on it
+( http://vizzzion.org/?blogentry=819 ), and requires in depth changes to
+accommodate them. 
+
+That's just very pragmatic high level points, explaining why we should
+avoid them. Please note that I do not even of ethics or anything, just
+real life impacts ( impact that people tend to forget to replace them by
+philosophical point since that's easier to dismiss as "non important",
+but that's just wrong ).
+
+On a more precise point of distributing when the developers do not want
+us to do ( like flash, etc ), using a download script is just a ugly
+hack as said in the past, since :
+
+- it can break at each change of the website, thus requiring a quick
+fix, and sometimes a not so easy one ( what if adobe start to really
+protect flash download with a more convoluted approach, like some kind
+of JS ? ). So that's fragile and demanding more work. 
+
+- it can be made illegal ( or at least, not authorized by the license
+that people never read ). Maybe it is already the case for some
+software. Maybe that's not legit to have a contract in electronic form.
+While the risk is IMHO rather low, things may changes. I am sure that
+Gael Duval didn't think "I could have issues by creating a small
+distribution called mandrake". He rightfully thought he would be
+protected. Yet, I would rather be cautious to not be too adventurous,
+especially for non cooperative software.
+As a side note, that would be one reason for me to not propose myself as
+president and/or treasurer of the association ( or if I do, . 
+
+- it doesn't work without a working internet connexion. While
+flash-plugin and skype are not useful without network access ( so that
+point is silly ), some others tools can be, and this would bring more
+frustration to people, and more risk of weird errors. I am pretty sure
+that people will be puzzled if everything work from their own mirror,
+except a few software.
+
+Personally, I aim for better stuff than fragile unsustainable hacks like
+this. And we should not start to settle on lower standards, especially
+if forced to us by non cooperative company or group. One could be
+tolerable. Two, likely. More, that's starting to generalize, and that's
+just sending the wrong signal to the whole community, and saying to
+company "it is ok to treat us like parias". It is hard to be credible
+when saying "we want to provides a solid system" and in the same time,
+do the contrary.
+
+I doubt we will be able to bring real long term credibility and a
+reputation for quality if we go this way. People can just compare Ubuntu
+reputation to Debian one, and see which one was able to survive without
+spending million of dollars each year. And also which one serve as a
+base for the other.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1