http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh also installs mono

[Max TenEyck Woodbury]

On 06/05/2012 01:50 AM, Hin-Tak Leung wrote:
> --- On Mon, 4/6/12, Max TenEyck Woodbury<max at mtew.isa-geek.net>  wrote:
>
>> On 06/04/2012 03:05 AM, Frédéric
>> Delanoy wrote:
>>> On Mon, Jun 4, 2012 at 8:35 AM, Dan Kegel<dank at kegel.com>
>> wrote:
>>>> On Sun, Jun 3, 2012 at 11:20 PM, Frédéric
>> Delanoy
>>>> <frederic.delanoy at gmail.com>
>> wrote:
>>>>> On Sun, Jun 3, 2012 at 7:02 PM, Dan Kegel<daniel.r.kegel at gmail.com>
>> wrote:
>>>>>> http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh
>>>>>> now also installs mono. ...
>>>>>
>>>>> Wouldn't it be better (and more acceptable for
>>>>> people disliking/wanting to avoid mono) to
>>>>> - keep install-gecko.sh as is
>>>>> - create install-mono.sh
>>>>> - create wine-install-addons.sh calling the
>>>>> former ?
>>>>
>>>> The point of this script is to make life easier for
>>>> me and for the average user.  It's not to make life
>>>> easier for people who don't like mono, mostly
>>>> because I doubt there are many of them.
>>> My comment was not only meant for "mono-haters", but it
>>> can also be useful IMHO to split e.g. to limit download
>>> size when one doesn't even need mono, and it maybe
>>> clearer as well ("addons" is pretty generic).
>>>
>>> Frédéric
>>>
>>>
>>
>> Actually, it really is the name that matters.  'mono'
>> is a lightning rod for a lot of political history.
>> If you were to integrate the same  functions into
>> Wine itself, and hopefully avoid tripping over the
>> stinking Microsoft patents, that set of problems can be
>> avoided,
>>
>> A native MSWindows application that wants .net support would
>> either connect to the installed dll that provides the
>> required services or install such a dll.  It would know
>> nothing about 'mono'.  It is only non-MSWindows platform
>> programs that will try to link to the  non-MSWinows
>> libraries in 'mono'.
>>
>> So an MSWindows executable looking for .net support needs
>> .net support, NOT mono.  We can and should provide such
>> executables the services they need.  However we should
>> NOT make it easy for programs from other platforms to
>> fall into the stinking Microsoft Patent  trap.  That
>> gateway to hell is called 'mono' and we should NOT open it.
>
> This is irrational bias against mono. The fact is that,
> since Vista, .Net Framework runtime is shipped as standard
> in windows. Therefore any windows application has a
> reasonable expectation of assuming .Net runtime to be
> around, and not prompt the user to go and download the
> .net runtime from microsoft. Athough some application does
>explicitly test for the presence of .net runtime and make
>the user go and download it from microsoft when it cannot
>detect such or when the version of net runtime is too low
>(i.e. if the user tries to install such software on XP).
>
> Granted the authentic MS .net runtime can be installed and
>works well enough under wine; but would you rather the
>user goes and download genuine MS .net and install it on
>wine? If you say downloading .net runtime and using that on
>linux is preferable from your point of view, I have nothing
>more to say...
>
The issue is access from linux native code to the .net
framework.  That should require a specific decision on the
part of the system administrator to make it available.  It is
that package that I believe is called 'mono'.  I have taken
steps to assure that it never appears on the systems I run.

Providing a .net framework to MSWindows platform applications
that I want to run on my systems is another mater.  Wine
should provide that framework on demand but that is NOT
'mono'.  The Wine .net support does NOT make the .net
framework available to native linux application.  (If it
IS provided a part of the wine migration library, I will
grumble but not scream about it.)

The problem is the lawyers and senior management at
Microsoft.  They have been caught laying traps for anything
competitive with their products.  There are 'markers' that
they use to make springing their trap easier.  One of those
markers is the name 'mono'.

The people who built the original 'mono' have been identified
as Microsoft shills.  They have NOT kept their development
environment clean.  It is known to be contaminated with
Microsoft's 'IP'.

Wine, on the other hand, has tried quite hard to prevent
contamination by Microsoft 'IP'.  I am seriously concerned
that accepting anything with the name 'mono' on it will
have the appearance of being contaminated, and even more
important, might cause some developers to relax their
standards and inadvertently accept pieces from the 'mono'
project instead of doing a clean re-implementation.