[Rd] R, Wine, and multi-threadedness.

[Marc Schwartz (via MN)]

On Thu, 2005-10-13 at 18:02 +0100, Hin-Tak Leung wrote:
> Prof Brian Ripley wrote:
> > On Thu, 13 Oct 2005, Marc Schwartz (via MN) wrote:
> <snipped>
> >>Sorry for jumping in here and no disrespect intended to anyone, but I am
> >>confused relative to the desire and benefits of running R under Wine on
> >>Linux simply for the sake of using the RGui.exe menus, when there are
> >>other substantive tradeoffs relative to running R natively on Linux, as
> >>Prof. Ripley has noted.
> > 
> > 
> > One reason for doing so is to be able to prepare for teaching in a Windows 
> > environment: I believe this is why it is mentioned in the FAQ.  (I 
> > personally test on the machine to be used just to be sure things work.)
> 
> I agree; and being able to discuss it with another user who may be
> on windows. Having alternatives and choices is good.

No disagreement that choice is good and that is a significant predicate
in the open source world. Please don't misconstrue my comments as being
in the context of pure Linux advocacy. They are not.

It was more to gain an understanding of the requirements you have to
comprehend the desire to take this particular approach and to
differentiate specific "isolated" requirements versus day-to-day routine
needs.

> Actually my earlier failed incentive was to run the Sciview-R GUI. It
> most certainly looks very useful and functional from the screenshots,
> and I dare say it is probably one of the best available - it is hard
> to imagine one "better" - the unix fanatics around me told me about
> ESS and I do have it installed and configured, but it isn't
> anywhere close to the Sciview-R GUI - sadly it is heavily .NET based
> and won't run under wine, which only recently moved to emulate 2k
> as default and have very little support for xp, 2k3 and the
> more security-conscious part of the NT families. I did install
> sciview-R successfully, but as soon as I see the manifest files,
> I realise it won't run under wine, not a hope.
> 
> Would be interesting to see if they are can port that to GTK#/mono
> on linux.

Perhaps you would be willing to contribute your time to make that
happen, presuming that the technical hurdles are resolvable.

> >>The one "advantage" that I had seen some time ago, was the possibility
> >>of being able to generate metafile graphics for inclusion with MS Office
> >>apps by using the native Windows libs (in a dual-boot scenario as I
> >>recall). However other substantively better options for generating high
> >>quality graphics have been proposed and discussed here frequently.
> > 
> > 
> > I am not 100% convinced that they are `substantively better' in all 
> > environments, and I still do that sometimes.
> 
> I agree on principle - until the linux port can do *exactly* the
> same thing better and more, "substantively better" is a
> rather subjective description and is just for the fanatics. If
> it is missing just one feature, like WMF export - and since microsoft
> is not going bankrupt any time soon, MS office integration is
> fairly important to *some* people - one cannot say it is
> 'substantially better', because there is always one user who would
> judge that one missing feature, over and above any other advantage.
> 
> Some software on linux uses libwmf for wmf import/export (I believe
> it is gimp). Maybe R can do the same.

Well, we have shown that libEMF is problematic. So if you want better
functionality here, you would be better served working with the libEMF
developers to enhance their compatibility. Though, as Prof. Ripley has
noted, there are problems with WMF/EMF files being imported into Office
apps, even when natively generated on Windows.

MS may not be going out of business in the near future, but the
continued pressure of open standards (as just recently noted here in the
Commonwealth of Massachusetts) will pressure MS over time to either
adopt (and adapt to) open standards or to experience a decline in market
share. It is suggested that the just announced inclusion of PDF
functionality in the upcoming Office 12 is a direct result of the
Massachusetts decision to require either OpenDoc or PDF formats.

But that's a different discussion for a different forum...

Relative to the "there is always one user" notion, being a firm believer
in Pareto's 80/20 Rule, no business or venture, whether for profit or
otherwise, can afford to meet the needs of 100% of the target
marketplace. You will not survive if that is your goal. There are some
users, for whom taking the time to meet their needs, will result in your
inability to meet the needs of the majority of your users and you will
ultimately lose them. That is called the "Opportunity Cost" and is
intrinsic given the predicate that resources are finite. Having the
discipline to say "No", that there is some "business" that is not worth
having, is a critical part of the decision making process.

The advantage of open source, is that you can build upon the basic
"product" and tailor it to your specific needs, if you have the
motivation and the time to do it yourself, or the ability to pay someone
else to do it for you.

Marc