Countering arguments against Wine
I've run into people several times who dislike the fact that I advocate or even work on the Wine project, because they feel that it takes focus away from working on the Linux desktop. I beg to differ, but I've never had a really snappy comeback for them. It happened again today, and this time it occurred to me I should write a page on the topic to organize my thoughts. Here it is: http://www.kegel.com/wine/why.html Comments welcome. Thanks, Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
On Fri, 29 Oct 2004 23:40:38 -0700, Dan Kegel <dank(a)kegel.com> wrote:
I've run into people several times who dislike the fact that I advocate or even work on the Wine project, because they feel that it takes focus away from working on the Linux desktop. I beg to differ, but I've never had a really snappy comeback for them. It happened again today, and this time it occurred to me I should write a page on the topic to organize
These aren't exactly buried, but they're not obvious either: http://www.winehq.com/site/myths http://www.winehq.com/site/why -Brian
Brian Vincent wrote:
On Fri, 29 Oct 2004 23:40:38 -0700, Dan Kegel <dank(a)kegel.com> wrote:
These aren't exactly buried, but they're not obvious either:
http://www.winehq.com/site/myths http://www.winehq.com/site/why
I had a link to the 2nd one, now I've got a link to the 1st one, thanks. Those pages are good, but I wanted one that focused in on just this one question. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Dan Kegel wrote:
I've run into people several times who dislike the fact that I advocate or even work on the Wine project, because they feel that it takes focus away from working on the Linux desktop. I beg to differ, but I've never had a really snappy comeback for them. It happened again today, and this time it occurred to me I should write a page on the topic to organize my thoughts. Here it is: http://www.kegel.com/wine/why.html Comments welcome.
Thanks, Dan
Dan, first of all, thanks for writing that dowm. I agree with what you say, until you reach the "But doesn't Wine take away the incentive for native ports?" section. I actually appreciate this reason, as it clarifies a 'feeling' that I've been unable to clearly express about this issue: 2. once Linux's market share is above 20%, there will be a strong economic incentive to do native Linux ports anyway, because running a Windows app under Linux will always feel strange. But I wonder if this is in fact true. I am a pure Linux user; I began my migration a year and a half ago, moving from a dual-boot, to a multi-boot (2 versions of Windows and 5 distributions of Linux on one system), and finally ditched all alternate boots except the Linux a few months ago. So I'm not all that far from the migration mindset, since I used Windows for over 10 years, but as a pure Linux user, I'm not all that close to it anymore, either. I've got Wine running, and installed several programs I was familiar with under Windows, mostly to perform tasks that I couldn't figure out how to do under Linux, but which I either knew how to perform using Windows apps, or could find HOW-TOs for that specified Windows apps. I find that it doesn't necessarily "feel strange" or at least as strange as I might have imagined. What mostly feels strange is the complications of getting the program started in the first place (having to cd to the application folder to run wine <program_name> from a terminal, or having to write a little start script in order to make a panel shortcut to it). Once the program is running, though, it doesn't "feel" strange at all; after all, the reason I'm running it is most likely because I'm familiar with it. This of course, assumes that the program in question runs well under Wine, which we will assume for the sake of this discussion, if you don't mind ;-) . I have admittedly found that it's ultimately "easier" (for me) to re-encode a video with transcode and mplex than it is to do so using TMPGEnc under Wine, which was a surprise given that I know squat about re-encoding video (I know somewhat more, now, though). I also found that given a choice between equivalent Linux native programs and Windows programs under Wine (Aisle Riot and Pretty Good Solitaire), I'll often choose the Linux native program simply because it's easier to *start* (not because I prefer it, per se). Maybe that's what you (and I) mean by "feeling strange", but since I'm not sure what causes this feeling, I am not certain that migrating XP users, who are used to and have no complaints with XP functionality but rather are migrating because they don't like the Windows security model (or lack therof)-- meaning, for practical reasons such as increasing cost for less value, rather than philosophical ones such as a deep objection to Windows' design philosophy or business practices-- would feel the same way after switching to Linux. All of those "a computer is just a tool" people who find it more strange and painful to use the command-line, or get confused if they have to read --help output or a man page "just to get something done" may well find that their relief at having these familiar tools available swamps any "strange" feelings of (guilt,irritation?) that they may (or may not) experience when running Windows programs under Linux. After all, you'll only have those feelings if you *care*-- and many, many users don't. If I come up with a "better" reason #2, I'll let you know ;-) . Holly
Holly Bostick wrote:
I've got Wine running, and installed several programs I was familiar with under Windows, mostly to perform tasks that I couldn't figure out how to do under Linux, but which I either knew how to perform using Windows apps, or could find HOW-TOs for that specified Windows apps. I find that it doesn't necessarily "feel strange" or at least as strange as I might have imagined. What mostly feels strange is the complications of getting the program started in the first place (having to cd to the application folder to run wine <program_name> from a terminal, or having to write a little start script in order to make a panel shortcut to it).
Man, oh, man is that strange for the average Windows user.
Once the program is running, though, it doesn't "feel" strange at all; after all, the reason I'm running it is most likely because I'm familiar with it. This of course, assumes that the program in question runs well under Wine, which we will assume for the sake of this discussion, if you don't mind ;-) .
I suspect that the drive letters being different adds a bit of runtime strangeness. And then there's a good chance that integration between Windows apps and native Linux apps will suffer. Finally, in all but the best-supported apps, Wine still has problems with lesser-used corners, and has subtly different appearance, if I'm not mistaken.
Maybe that's what you (and I) mean by "feeling strange", but since I'm not sure what causes this feeling, I am not certain that migrating XP users, who are used to and have no complaints with XP functionality but rather are migrating because they don't like the Windows security model (or lack therof)-- meaning, for practical reasons such as increasing cost for less value, rather than philosophical ones such as a deep objection to Windows' design philosophy or business practices-- would feel the same way after switching to Linux.
The great majority of Windows people will hate the entire idea of switching. They don't care about Linux in the least. They aren't switching 'because of' anything other than a) the computer was cheaper with Linux, or b) their company is switching to Linux. In either case, they expect their computer to Just Work Like It Did Before, and my suspicion is that a mixed system of Linux and Windows apps running under Wine will always have more glitches of one sort or another than a full set of native Linux apps.
If I come up with a "better" reason #2, I'll let you know ;-) .
Please do! - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Holly Bostick wrote:
Dan Kegel wrote:
I've run into people several times who dislike the fact that I advocate or even work on the Wine project, ... Dan
Dan, first of all, thanks for writing that dowm.
Thank you indeed Dan! If I encounter Mike Hearn yet again with his "Darwine is Pointless" arguments I can sed 's/Wine/Darwine/ s/Linux/Mac OS X/' in reply to him. Jim White
On Sun, 31 Oct 2004 01:26:21 -0800, Jim White <jim(a)pagesmiths.com> wrote:
Thank you indeed Dan! If I encounter Mike Hearn yet again with his "Darwine is Pointless" arguments I can sed 's/Wine/Darwine/ s/Linux/Mac OS X/' in reply to him.
Huh? I just went back through the archives and couldn't find any reference like that. Do you have a link to the thread or was it a private email? The closest I saw was this exchange where you wrote: "This is the more general project that has emerged from my initial idea for Darwine, namely X86/Linux binary compatibility for OS X. " Mike replied: "Hmm, what is that useful for? Nearly all software for Linux is open source and can be ported or sometimes simply recompiled for any given platform." That wasn't speaking about Wine. -Brian
On Sat, Oct 30, 2004 at 04:32:02PM +0200, Holly Bostick wrote:
find that it doesn't necessarily "feel strange" or at least as strange as I might have imagined. What mostly feels strange is the complications of getting the program started in the first place (having to cd to the application folder to run wine <program_name> from a terminal, or having to write a little start script in order to make a panel shortcut to it).
You might look into the kernel's miscellaneous binary format support. On my Debian system, with binfmt-support package installed, I can directly execute a PE executable (WINE is invoked automatically by the kernel). -- Ryan Underwood, <nemesis(a)icequake.net>
Ryan Underwood wrote:
On Sat, Oct 30, 2004 at 04:32:02PM +0200, Holly Bostick wrote:
find that it doesn't necessarily "feel strange" or at least as strange as I might have imagined. What mostly feels strange is the complications of getting the program started in the first place (having to cd to the application folder to run wine <program_name> from a terminal, or having to write a little start script in order to make a panel shortcut to it).
You might look into the kernel's miscellaneous binary format support. On my Debian system, with binfmt-support package installed, I can directly execute a PE executable (WINE is invoked automatically by the kernel).
Yes, I've just installed that for the first time during my recent kernel upgrade. Haven't really tested it out, though. However, I think that the presence of this ability is not necessarily a strong counter-argument since 1) it requires the user to either be quite familiar with their system, or know such a person, in order to set it up in the first place, and 2) is not necessarily useful if you have more than one Wine variant (or version) on the system (haven't checked this out either, but I expect problems). It is not necessarily unreasonable for a home, multi-user computer to "need", let us say, Crossover Office (or regular Wine) for Dad's work, and Cedega (or regular Wine, possibly a different version) for the kids' games. What binary is going to be invoked when the user double-clicks, if different applications need to be run with different versions/types of Wine? OK, I'll grant you that if a user knows how to install multiple versions of Wine on a system without conflict, they probably won't care about this double-clicking business in the first place, and I'll also grant that Wine is not CX is not Cedega-- but... we're talking about often inexperienced people who are likely relying on Windows programs as a crutch to avoid the "confusingness" of Linux in the first place (the issue in question is easing migration woes, after all). Such a user, when informed that CX is good for apps, and Cedega is good for games, might well install both, which is possible to do without problems, afaik (as they install in different places, and the wine or cx binaries and the cedega binaries do not have the same name). So what's going to happen with the file associations on which the double-click strategy relies? Games are not distinguished from MSOffice in terms of being some other mime-type than "DOS/Windows executable". Is CX going to try to open FarCry? Or is Cedega going to try to open Photoshop? I really don't know (not having tried this), but I wonder, and suspect that it would bite me in the butt if I did try. So while I do appreciate this functionality, I'm not sure it's flexible enough to cover the vast range of strange things that former Windows users might do (given that they're under the general impression that they can just click once and accomplish anything, no matter how complex or technically difficult-- through no fault of their own, I might add; they've just been sold a bill of goods, no pun intended). Holly
On Tue, Nov 02, 2004 at 03:47:40AM +0100, Holly Bostick wrote:
What binary is going to be invoked when the user double-clicks, if different applications need to be run with different versions/types of Wine?
One could just offer a script that toggles the version of Wine being used. Click on the script, dialog box pops up "Windows programs will now be launched using Wine[X]", and maybe some more information regarding the suitability for games vs applications. On a Debian system, this would be handled through the alternatives system; the script just cycles through the available alternatives picking the next one each time it is invoked. On other systems, you can use /proc to modify the executable being used to launch anything with a PE header. -- Ryan Underwood, <nemesis(a)icequake.net>
On Sat, 06 Nov 2004 16:15:53 -0600, Ryan Underwood wrote:
One could just offer a script that toggles the version of Wine being used. Click on the script, dialog box pops up "Windows programs will now be launched using Wine[X]", and maybe some more information regarding the suitability for games vs applications. On a Debian system, this would be handled through the alternatives system; the script just cycles through the available alternatives picking the next one each time it is invoked. On other systems, you can use /proc to modify the executable being used to launch anything with a PE header.
It's slightly less pragmatic but the real solution is for WineHQ Wine to be good at everything ;) The CrossOver secret sauce is mostly the fact that we put together controlled, stabilised [binary] packages and because we collectively write so much code, we understand how to get the best out of it. That's really what it boils down to. There's no reason regular Wine can't be like that too, one day. As for Cedega/WineX - well, they have a big lead in gaming, but I'd like to think that one day Wine will be the swiss-army knife of Windows emulation. Regular Wine does have DX support, we should work on that rather than be distracted by a pseudo-proprietary fork. thanks -mike
Mike Hearn wrote:
As for Cedega/WineX - well, they have a big lead in gaming, but I'd like to think that one day Wine will be the swiss-army knife of Windows emulation. Regular Wine does have DX support, we should work on that rather than be distracted by a pseudo-proprietary fork.
thanks -mike
I would like that too, actually, and I doubt I'm alone. Did you hear that TG is now offering a time-limited demo version so you can (finally) try before you buy? The thing is, this fragmentation of the Wine project really hurts Wine as a whole, and it just makes me wild. It's confusing to people who simply want to run their programs. Wine actually works better than people are led to believe by the general scuttlebutt. WineX/Cedega does not work as well as TG would have one believe (not to mention that many users object to the way TG chooses what individual games to build support for, without regard to other games of the same class/engine, or fairly often breaking something that did work under previous versions). Crossover seems to be damn near perfect-- as long as you stay within its definitions of what it will deal with (but what it will deal with, it won't screw up in any way whatsoever, which is more than you can say for the other two variants). So how are Bob and Betty Newbie (and their kids) supposed to know what to do when they need to run a Windows program? There's no Big Board to say "if Program X then do this; if Program Y, then do that." And we all surely know the consequences of trying to figure out which version of which Wine variant runs any given application. And if you can't figure that out, you will have a (very) bad impression of the project as a whole, which is an argument that cannot be effectively countered. Amazingly, in this sea of confusion, Wine appears to be the stable(st) leg. Crossover is a great product, but is not so flexible (on purpose, no offence intended). Cedega is just not stable; no one knows from version to version whether something that worked is going to be broken, no one knows when support for desired things (new or old) is going to show up; you just pay with a leap of faith-- which many people understandably object to. Wine, on the other hand, gives a general impression of moving forward at all times. Yes, there are regressions; yes, things break that used to work. But because Wine works on supporting APIs and functions, rather than specific applications (which policy I support when Crossover does it, and object to when TG does it), when DX8 applications get working "perfectly" under Wine, I (as a user) can feel confident that *all* DX8 apps will then work (at least as far as DX is concerned, notwithstanding quirks of individual apps). Which for me as a user, is much more of a load off my mind in terms of trying to keep track of how to get whatever random app I or my family might want to run working, than trying to read anybody's (or in fact, everybody's) application database(s) to try to figure out how best to proceed, as I currently must do. And Wine really does get noticeably better from month to month, which is quite heartening-- and the fact that the project exudes a sense of hopefulness is not to be sneezed at. People are confused by many of the changes, but in case no one has bothered to say, symlinking the drive paths is *brilliant*. The auto-setup on first run is pretty cool, too. And I can certainly attest that I have run several programs that are supposed to work better on WineX (as it was then), which in fact ran better on Wine (or in fact, ran only on Wine). Not to mention that WineHQ is the source of all in the first place, and that to WineHQ we have no ethical objections (as so many do with TG). Oh yes, I would love to see Regular Wine become the Swiss Army Knife that it is meant to be, that users expect it to be, and that it deserves to be. Then we won't have to counter any arguments, because "is Wine a good thing or a bad thing?" becomes a matter of pure philosophy-- and users don't have time to argue philosophy, being busy actually getting something done, using tools that work. Holly
participants (6)
-
Brian Vincent -
Dan Kegel -
Holly Bostick -
Jim White -
Mike Hearn -
Ryan Underwood