http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh now also installs mono.
It should be probably be called wine-install-addons.sh now, maybe I'll rename it that soon. If you have a better idea for the name, let me know.
(I've also deprecated the copy that was in winezeug; that one now just tells users to get it from the winetricks repo.)
On Sun, Jun 3, 2012 at 7:02 PM, Dan Kegel daniel.r.kegel@gmail.com wrote:
http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh now also installs mono.
It should be probably be called wine-install-addons.sh now, maybe I'll rename it that soon. If you have a better idea for the name, let me know.
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 ?
Frédéric
On Sun, Jun 3, 2012 at 11:20 PM, Frédéric Delanoy frederic.delanoy@gmail.com wrote:
On Sun, Jun 3, 2012 at 7:02 PM, Dan Kegel daniel.r.kegel@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. - Dan
On Mon, Jun 4, 2012 at 8:35 AM, Dan Kegel dank@kegel.com wrote:
On Sun, Jun 3, 2012 at 11:20 PM, Frédéric Delanoy frederic.delanoy@gmail.com wrote:
On Sun, Jun 3, 2012 at 7:02 PM, Dan Kegel daniel.r.kegel@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
On Mon, Jun 4, 2012 at 12:05 AM, Frédéric Delanoy frederic.delanoy@gmail.com wrote:
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).
The script only has to be run once, so download size isn't really an issue. From the user's point of view, having a single script to get rid of all the !#&# download prompts is ideal, and splitting it would add complexity. - Dan
On Mon, 4 Jun 2012 06:24:26 -0700 Dan Kegel dank@kegel.com wrote:
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.
There are many average users using apps that require real .NET. It doesn't make sense to force them to install mono and then have to uninstall it.
Actually, now that I'm looking at the script a little more carefully, it doesn't actually install anything, just puts the installers in a place where Wine can find them. So if you already have native .NET installed, you won't get wine-mono in your prefix.
If you're planning to install it, I'd argue that letting it install and letting winetricks remove it is faster than dismissing the dialog.
It seems it would make sense to continue grabbing all the stable versions as new ones come out, since old versions of Wine will look for the old .msi installers. Sorry I misled you earlier, Dan.
On 06/04/2012 03:05 AM, Frédéric Delanoy wrote:
On Mon, Jun 4, 2012 at 8:35 AM, Dan Kegeldank@kegel.com wrote:
On Sun, Jun 3, 2012 at 11:20 PM, Frédéric Delanoy frederic.delanoy@gmail.com wrote:
On Sun, Jun 3, 2012 at 7:02 PM, Dan Kegeldaniel.r.kegel@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.
On Mon, Jun 4, 2012 at 12:23 PM, Max TenEyck Woodbury max@mtew.isa-geek.net wrote:
<mono hate>
Let's not hijack Dan's thread for this.
--- On Mon, 4/6/12, Max TenEyck Woodbury max@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 Kegeldank@kegel.com
wrote:
On Sun, Jun 3, 2012 at 11:20 PM, Frédéric
Delanoy
wrote:
On Sun, Jun 3, 2012 at 7:02 PM, Dan Kegeldaniel.r.kegel@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...
On 06/05/2012 01:50 AM, Hin-Tak Leung wrote:
--- On Mon, 4/6/12, Max TenEyck Woodburymax@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 Kegeldank@kegel.com
wrote:
On Sun, Jun 3, 2012 at 11:20 PM, Frédéric
Delanoy
wrote:
On Sun, Jun 3, 2012 at 7:02 PM, Dan Kegeldaniel.r.kegel@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.
On 06/05/2012 08:53 AM, Max TenEyck Woodbury wrote:
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
That's *exactly* what wine-mono *IS*. Unlike before this is the Windows version of mono and thus unusable from Linux.
IS provided a part of the wine migration library, I will grumble but not scream about it.)
bye michael
--- On Tue, 5/6/12, Max TenEyck Woodbury max@mtew.isa-geek.net wrote:
The issue is access from linux native code to the .net framework. <snipped>
Please stop your anti-mono ranting. You have no idea what you are talking about. wine-mono is an modified version of a *win32* build of mono. wine-mono does not interact with linux native code at all. It is a win32 PE build of mono. Got it?
On Mon, 4 Jun 2012, Max TenEyck Woodbury wrote: [...]
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.
[...]
You obviously have absolutely no idea what the wine-mono package is for. You should read up and apologize.
On 06/05/2012 03:00 AM, Francois Gouget wrote:
On Mon, 4 Jun 2012, Max TenEyck Woodbury wrote: [...]
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.
[...]
You obviously have absolutely no idea what the wine-mono package is for. You should read up and apologize.
NO APOLOGY! You are missing the point.
If it is NOT a linux native interface, it is NOT an analog of 'mono'. Call it what it is: DotNetFramework or something like that. Just do NOT make the mistake of tying it to the contaminated package, even if it is only by using a similar name.
This is because legal risks are fairly high here, and APPEARANCE does account for a lot in that domain. While the odds are somewhat in favor of any legal action coming out correctly if the tech is right, it IS a crap shoot and the lawyer's are the only sure winners.
If it is NOT a linux native interface, it is NOT an analog of 'mono'.
Mono is available on many platforms, including Windows. What we have is a fork/package of Mono that is built for Windows and only used by Wine's internals. If Mono is "contaminated" then our package is just as much so.
On Windows, mscoree.dll is the interface that programs use to access the .NET runtime. However, the .NET runtimes are separate; mscoree is only the interface to them. We have an implementation of mscoree.dll in Wine, and our implementation uses Mono (which is in the wine-mono package) as its .NET runtime. The interface that mscoree uses to access Mono is the Mono embedding API. While the package also contains some other things that are specific to .NET, the core of it is Mono.
You obviously have absolutely no idea what the wine-mono package is for. You should read up and apologize.
NO APOLOGY! You are missing the point.
You are missing the point. You're argument lacks weight because you clearly have no idea what you're talking about. One cannot base a reasonable argument on top of displays of ignorance and irrationality. You can try but in the end you only look like an ass. I understand that you're very passionate about the subject but understand that such displays harm your cause more than help it.
You were wrong on several technical details which you based several key points of your argument on. A reasonable thing to do would be to offer an apology while moving on to other points you feel more sure about. Instead you respond with more rudeness.
At this point I don't think you can recover well enough to have a meaningful discussion. You should make a strategic withdrawal, do some research, and reform your argument.
On 06/05/2012 01:16 PM, James Eder wrote:
You obviously have absolutely no idea what the wine-mono package is for. You should read up and apologize.
NO APOLOGY! You are missing the point.
You are missing the point. You're argument lacks weight because you clearly have no idea what you're talking about. One cannot base a reasonable argument on top of displays of ignorance and irrationality. You can try but in the end you only look like an ass. I understand that you're very passionate about the subject but understand that such displays harm your cause more than help it.
You were wrong on several technical details which you based several key points of your argument on. A reasonable thing to do would be to offer an apology while moving on to other points you feel more sure about. Instead you respond with more rudeness.
At this point I don't think you can recover well enough to have a meaningful discussion. You should make a strategic withdrawal, do some research, and reform your argument.
It is not so much the technical details that are the problem.
It is the LEGAL problems and potential legal problems that are at the root of my complaint.
Telling me that I have the technical details wrong does not help. I have very carefully tried to move the discussion away from secondary technical points and onto the strategic issues that are not being addressed.
I find it very frustrating that the technical points are made over and over as if they were somehow answers to the legal and strategic problems. If you think I have been rude, consider that ignoring the more important issues that I am trying to raise is equally if not more rude.
If I have resorted to name calling or personal characterizations, then I do owe you all an apology, but I do not apologize for trying to get the non-technical aspects of the problem presented.
It is not so much the technical details that are the problem.
It is the LEGAL problems and potential legal problems that are at the root of my complaint.
Telling me that I have the technical details wrong does not help. I have very carefully tried to move the discussion away from secondary technical points and onto the strategic issues that are not being addressed.
Well, it didn't seem like you were interested in diving into specifics. I don't know the details of Microsoft's patents relating to .NET or any promises they've made regarding those patents. Even if I did, I'm probably not qualified to evaluate them. I simply assumed that because so many mainstream distros and open source projects seemed to think that use of Mono didn't pose a significant legal risk, it wasn't a problem to include it in Wine.
If there's some specific action we could take to reduce our legal risk without impairing Wine's compatibility with Windows, we should probably do that and/or ask Mono to do it. However, it seems unlikely to me that there is something Wine could do in this area that Mono cannot, and I am not in a position to go looking for patents that might be relevant to our use case.
This may be naive, but it seems obvious to me that the technical details are what ultimately determine the legal situation, and appearances have a much smaller effect. You also have to understand that this is a development mailing list, and it's full of programmers, not lawyers. So there's far more knowledge here of technical details (personally, I consider those details my responsibility) than legal strategy.
On Wed, Jun 6, 2012 at 3:36 PM, Vincent Povirk madewokherd@gmail.com wrote:
It is not so much the technical details that are the problem.
It is the LEGAL problems and potential legal problems that are at the root of my complaint.
Telling me that I have the technical details wrong does not help. I have very carefully tried to move the discussion away from secondary technical points and onto the strategic issues that are not being addressed.
Well, it didn't seem like you were interested in diving into specifics. I don't know the details of Microsoft's patents relating to .NET or any promises they've made regarding those patents. Even if I did, I'm probably not qualified to evaluate them. I simply assumed that because so many mainstream distros and open source projects seemed to think that use of Mono didn't pose a significant legal risk, it wasn't a problem to include it in Wine.
If there's some specific action we could take to reduce our legal risk without impairing Wine's compatibility with Windows, we should probably do that and/or ask Mono to do it. However, it seems unlikely to me that there is something Wine could do in this area that Mono cannot, and I am not in a position to go looking for patents that might be relevant to our use case.
This may be naive, but it seems obvious to me that the technical details are what ultimately determine the legal situation, and appearances have a much smaller effect. You also have to understand that this is a development mailing list, and it's full of programmers, not lawyers. So there's far more knowledge here of technical details (personally, I consider those details my responsibility) than legal strategy.
The core of mono is safe. It is covered under ECMA-334 (C# language) and ECMA-335 (CLIR vm). The mono MS Compatibility Stack, which includes: - XML - ASP.NET - Windows.Forms - ADO.NET - Core cryptography - Transactions
is a grey area now since the project is not part of Novell anymore. Novell and Microsoft had joint patent agreement, so there were no problems. So the question is, does wine-mono include the compatibility stack?
- Matijn
The core of mono is safe. It is covered under ECMA-334 (C# language) and ECMA-335 (CLIR vm). The mono MS Compatibility Stack, which includes:
- XML
- ASP.NET
- Windows.Forms
- ADO.NET
- Core cryptography
- Transactions
is a grey area now since the project is not part of Novell anymore. Novell and Microsoft had joint patent agreement, so there were no problems. So the question is, does wine-mono include the compatibility stack?
I know Windows.Forms is included. I'm not familiar with the other items, but if mono builds them by default then they're included.
-
Dan Kegel -
Dan Kegel -
Francois Gouget -
Frédéric Delanoy -
Hin-Tak Leung -
James Eder -
Matijn Woudt -
Max TenEyck Woodbury -
Michael Stefaniuc -
Rosanne DiMesio -
Vincent Povirk