I've long predicted that companies might use Wine for a while to ship Linux-compatible products, and later switch to a native build once they know they have users. Well, now we have at least one example of this: Bricscad (see http://www.bricsys.com ). This is a *good* thing, and validates somewhat the idea that Wine is a catalyst to enable a global shift from Windows to Linux.
Il 24/05/2010 02:39, Dan Kegel ha scritto:
I've long predicted that companies might use Wine for a while to ship Linux-compatible products, and later switch to a native build once they know they have users. Well, now we have at least one example of this: Bricscad (see http://www.bricsys.com ).
This is a *good* thing, and validates somewhat the idea that Wine is a catalyst to enable a global shift from Windows to Linux.
mhhhhh... I'm following bricscad development and I'd say that the winelib version was quite a flop.... too many problems and didn't have the expected success. The linux native version is (imho) a courageus effort of Bricsys team to give Linux something that was missing since too long time :-) Pity for the choice of wxwidgets, indeed.... it's becoming too old style, imho, and the portability level isn't that easy. Ciao Max
On Mon, May 24, 2010 at 6:46 PM, Dan Kegel <dank(a)kegel.com> wrote:
Max wrote:
the winelib version was quite a flop.... too many problems
Indeed. One should never release naked winelib apps. Instead, one should bundle the windows version with a private copy of Wine, like Picasa (and now at least one other app) have done.
Why is that better? What's the point of winelib then? Thanks, Avery
On Tue, May 25, 2010 at 10:21 AM, Avery Pennarun <apenwarr(a)gmail.com> wrote:
the winelib version was quite a flop.... too many problems
Indeed. One should never release naked winelib apps. Instead, one should bundle the windows version with a private copy of Wine, like Picasa (and now at least one other app) have done.
Why is that better? What's the point of winelib then?
Winelib is mostly useful when recompiling a windows app to run on a non-x86 platform (where win32 compilers aren't available). You could also use it to build a linux plugin for a windows app running on Wine. In either case, you probably want to bundle the Wine runtime with the app rather than trying to run against whatever Wine the user has. - Dan
On Tue, May 25, 2010 at 1:47 PM, Dan Kegel <dank(a)kegel.com> wrote:
On Tue, May 25, 2010 at 10:21 AM, Avery Pennarun <apenwarr(a)gmail.com> wrote:
the winelib version was quite a flop.... too many problems
Indeed. One should never release naked winelib apps. Instead, one should bundle the windows version with a private copy of Wine, like Picasa (and now at least one other app) have done.
Why is that better? What's the point of winelib then?
Winelib is mostly useful when recompiling a windows app to run on a non-x86 platform (where win32 compilers aren't available).
Ah, that makes sense.
In either case, you probably want to bundle the Wine runtime with the app rather than trying to run against whatever Wine the user has.
I guess this is because wine is such a moving target? It seems a shame to bundle a copy of wine with every single app, although I can definitely see how commercial products would want to do that to improve repeatability. One would hope that all the automated testing wine is doing lately would reduce the need for this kind of thing eventually. Thanks, Avery
On Tue, May 25, 2010 at 10:58 AM, Avery Pennarun <apenwarr(a)gmail.com> wrote:
In either case, you probably want to bundle the Wine runtime with the app rather than trying to run against whatever Wine the user has.
I guess this is because wine is such a moving target? It seems a shame to bundle a copy of wine with every single app, although I can definitely see how commercial products would want to do that to improve repeatability. One would hope that all the automated testing wine is doing lately would reduce the need for this kind of thing eventually.
Commercial apps should continue bundling their own wine no matter what we do, I think. It'll be a while before they can count on everyone already having a wine installed that can handle their app. And security concerns might prevent wine from being installed by default on some distros.
On 05/25/2010 11:39 AM, Dan Kegel wrote:
On Tue, May 25, 2010 at 10:58 AM, Avery Pennarun <apenwarr(a)gmail.com> wrote:
In either case, you probably want to bundle the Wine runtime with the app rather than trying to run against whatever Wine the user has.
I guess this is because wine is such a moving target? It seems a shame to bundle a copy of wine with every single app, although I can definitely see how commercial products would want to do that to improve repeatability. One would hope that all the automated testing wine is doing lately would reduce the need for this kind of thing eventually.
Commercial apps should continue bundling their own wine no matter what we do, I think. It'll be a while before they can count on everyone already having a wine installed that can handle their app. And security concerns might prevent wine from being installed by default on some distros.
I believe a reasonable alternative is to communicate directly with the distro Wine packager and have them test your app against whatever version of Wine they plan on shipping. That way you don't miss out on good changes in Wine either. In essence, you come to me with your app, have me verify the packaging and put it in the archive (or store if it's a paid app), and have it depend on the system Wine. Then I check it against every Wine version that gets into an official Ubuntu release. Thanks, Scott Ritchie
Scott Ritchie <scott(a)open-vote.org> wrote:
I believe a reasonable alternative is to communicate directly with the distro Wine packager and have them test your app against whatever version of Wine they plan on shipping. That way you don't miss out on good changes in Wine either.
That's unreasonable to put the testing burden of a commercial application to a 3rd party that's not a part of QA or a support team. Obviosuly you can't test all the aspects of the application, or even don't know how to do that, or testing requires additional data or tools. -- Dmitry.
On 05/26/2010 12:17 AM, Dmitry Timoshkov wrote:
Scott Ritchie <scott(a)open-vote.org> wrote:
I believe a reasonable alternative is to communicate directly with the distro Wine packager and have them test your app against whatever version of Wine they plan on shipping. That way you don't miss out on good changes in Wine either.
That's unreasonable to put the testing burden of a commercial application to a 3rd party that's not a part of QA or a support team. Obviosuly you can't test all the aspects of the application, or even don't know how to do that, or testing requires additional data or tools.
The idea is for the distro to become part of the QA process itself. By being forward about what version of Wine to ship (eg only the stable releases) the vendor can greatly narrow their testing focus. If multiple distros are using the same stable Wine version, that testing burden gets shared -- assuming the vendor even cares about more than a couple distros. This is, of course, assuming it's reasonable to stick to Wine's stable releases. That's only useful if they're relatively frequent - a year and a half was a bit too much time. I'm also, of course, assuming a distro that actively cares about Wine enough to devote some sort of QA resources towards it. Thanks, Scott Ritchie
On Wed, May 26, 2010 at 6:44 AM, Scott Ritchie <scott(a)open-vote.org> wrote:
On 05/25/2010 11:39 AM, Dan Kegel wrote:
On Tue, May 25, 2010 at 10:58 AM, Avery Pennarun <apenwarr(a)gmail.com> wrote:
In either case, you probably want to bundle the Wine runtime with the app rather than trying to run against whatever Wine the user has.
I guess this is because wine is such a moving target? It seems a shame to bundle a copy of wine with every single app, although I can definitely see how commercial products would want to do that to improve repeatability. One would hope that all the automated testing wine is doing lately would reduce the need for this kind of thing eventually.
Commercial apps should continue bundling their own wine no matter what we do, I think. It'll be a while before they can count on everyone already having a wine installed that can handle their app. And security concerns might prevent wine from being installed by default on some distros.
I believe a reasonable alternative is to communicate directly with the distro Wine packager and have them test your app against whatever version of Wine they plan on shipping. That way you don't miss out on good changes in Wine either.
In essence, you come to me with your app, have me verify the packaging and put it in the archive (or store if it's a paid app), and have it depend on the system Wine. Then I check it against every Wine version that gets into an official Ubuntu release.
Thanks, Scott Ritchie
They'd have to contact 300+ Linux distributions every +/- 6 months to ensure their application works on every version of every distribution - and that's only if every user uses the single Wine version that the distribution version originally shipped with. Maybe each distribution should instead adhere to LSB standards and pre-install the Autopackage/Zeroinstall runtimes which would allow third parties to package their own stuff and have it work out of the box on every distribution? Zeroinstall for example lets you parallel install several versions of the same package - so you could have a Wine version for a specific Winelib application and another Wine version for every other application. Thank you Damjan Jovanovic
participants (6)
-
Avery Pennarun -
Damjan Jovanovic -
Dan Kegel -
Dmitry Timoshkov -
Massimo Del Fedele -
Scott Ritchie