24 May
2010
24 May
'10
12:39 a.m.
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.
24 May
24 May
5:29 p.m.
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
25 May
25 May
5:21 p.m.
On Mon, May 24, 2010 at 6:46 PM, Dan Kegel <dank(a)kegel.com> wrote:
Max wrote:
Why is that better? What's the point of winelib then?
Thanks,
Avery
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.
5:47 p.m.
On Tue, May 25, 2010 at 10:21 AM, Avery Pennarun <apenwarr(a)gmail.com> wrote:
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
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.
5:58 p.m.
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:
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.
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. 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
6:39 p.m.
On Tue, May 25, 2010 at 10:58 AM, Avery Pennarun <apenwarr(a)gmail.com> wrote:
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.
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. 
26 May
26 May
4:44 a.m.
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:
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
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. 
7:17 a.m.
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.
2 Jun
2 Jun
9:06 a.m.
On 05/26/2010 12:17 AM, Dmitry Timoshkov wrote:
Scott Ritchie <scott(a)open-vote.org> wrote:
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
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.
26 May
26 May
8:27 a.m.
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:
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
On Tue, May 25, 2010 at 10:58 AM, Avery Pennarun
<apenwarr(a)gmail.com> wrote:
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 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.
5096
days inactive
5105
days old
10 comments
6 participants
participants (6)
-
Avery Pennarun -
Damjan Jovanovic -
Dan Kegel -
Dmitry Timoshkov -
Massimo Del Fedele -
Scott Ritchie