Keeping people from trying iTunes in Wine?
Watching Twitter, one fairly frequently seems people trying and failing to run iTunes 10 and the like in Wine. Should we let them bash their heads against the wall like that? Maybe we should detect the top ten apps that don't work with Wine, and put up a warning dialog saying they are known not to work, and people shouldn't try. (Kind of like what Windows 7 does when you do something dangerous, e.g. try to look at the contents of drive C:.)
You could also add Office 2010 to the list. :) Tom On Thu, Sep 9, 2010 at 3:59 PM, Dan Kegel <dank(a)kegel.com> wrote:
Watching Twitter, one fairly frequently seems people trying and failing to run iTunes 10 and the like in Wine.
Should we let them bash their heads against the wall like that?
Maybe we should detect the top ten apps that don't work with Wine, and put up a warning dialog saying they are known not to work, and people shouldn't try. (Kind of like what Windows 7 does when you do something dangerous, e.g. try to look at the contents of drive C:.)
-- Wine is not a conclusion but a process...
On 09/09/2010 12:59 AM, Dan Kegel wrote:
Watching Twitter, one fairly frequently seems people trying and failing to run iTunes 10 and the like in Wine.
Should we let them bash their heads against the wall like that?
Maybe we should detect the top ten apps that don't work with Wine, and put up a warning dialog saying they are known not to work, and people shouldn't try. (Kind of like what Windows 7 does when you do something dangerous, e.g. try to look at the contents of drive C:.)
This would be relatively simple to implement, and would even be doable with a shell script outside of Wine. Just md5sum the .exe, compare it with a blacklist, pop the warning if so, and if not pass it to the normal Wine process. Thanks, Scott Ritchie
On Thu, Sep 9, 2010 at 1:46 PM, Scott Ritchie <scott(a)open-vote.org> wrote:
This would be relatively simple to implement, and would even be doable with a shell script outside of Wine. Just md5sum the .exe, compare it with a blacklist, pop the warning if so, and if not pass it to the normal Wine process.
Wouldn't it be better to read the manifest/version information from the exe (and maybe the installer too)? I think there are too many versions of the exe to make md5 sums practical. Also, maybe it should be a warning with an option to ignore it :) Octavian
On Thu, 9 Sep 2010 00:59:32 -0700 Dan Kegel <dank(a)kegel.com> wrote:
Watching Twitter, one fairly frequently seems people trying and failing to run iTunes 10 and the like in Wine.
Should we let them bash their heads against the wall like that?
Maybe we should detect the top ten apps that don't work with Wine, and put up a warning dialog saying they are known not to work, and people shouldn't try. (Kind of like what Windows 7 does when you do something dangerous, e.g. try to look at the contents of drive C:.)
Do you really want to prevent users from ever testing these apps in new versions of Wine, or trying to find workarounds? I do a fair amount of head-bashing myself, and I would find such a message patronizing and intrusive. -- Rosanne DiMesio <dimesio(a)earthlink.net>
Rosanne DiMesio <dimesio(a)earthlink.net> wrote:
Maybe we should detect the top ten apps that don't work with Wine, and put up a warning dialog saying they are known not to work, and people shouldn't try.
Do you really want to prevent users from ever testing these apps in new versions of Wine, or trying to find workarounds?
No, I just want to give them fair warning they're about to pound sand. The dialog would have a 'Never show this dialog again' checkbox, and buttons for 'Give Up' and 'Full Speed Ahead, Damn The Torpedoes'.
I do a fair amount of head-bashing myself, and I would find such a message patronizing and intrusive.
You would then check the checkbox and click 'Geronimo'. - Dan
On Thu, Sep 9, 2010 at 8:34 AM, Rosanne DiMesio <dimesio(a)earthlink.net> wrote:
On Thu, 9 Sep 2010 00:59:32 -0700 Dan Kegel <dank(a)kegel.com> wrote:
Watching Twitter, one fairly frequently seems people trying and failing to run iTunes 10 and the like in Wine.
Should we let them bash their heads against the wall like that?
Maybe we should detect the top ten apps that don't work with Wine, and put up a warning dialog saying they are known not to work, and people shouldn't try. (Kind of like what Windows 7 does when you do something dangerous, e.g. try to look at the contents of drive C:.)
Do you really want to prevent users from ever testing these apps in new versions of Wine, or trying to find workarounds? I do a fair amount of head-bashing myself, and I would find such a message patronizing and intrusive.
Agreed. Wine doesn't make efforts to babysit users for most other things, I don't see why this should be any different. Also consider that if such a workaround were to go into wine, that code may long outlive the 'affected apps', and the list would quickly grow out of date. I suppose if a packager wanted to do something like this for their distro I wouldn't complain too much, unless users started asking about it in #winehq/the forums. But this _should not_ go into vanilla wine. -- -Austin
On Thu, Sep 9, 2010 at 5:47 PM, Austin English <austinenglish(a)gmail.com> wrote:
On Thu, Sep 9, 2010 at 8:34 AM, Rosanne DiMesio <dimesio(a)earthlink.net> wrote:
On Thu, 9 Sep 2010 00:59:32 -0700 Dan Kegel <dank(a)kegel.com> wrote:
Watching Twitter, one fairly frequently seems people trying and failing to run iTunes 10 and the like in Wine.
Should we let them bash their heads against the wall like that?
Maybe we should detect the top ten apps that don't work with Wine, and put up a warning dialog saying they are known not to work, and people shouldn't try. (Kind of like what Windows 7 does when you do something dangerous, e.g. try to look at the contents of drive C:.)
Do you really want to prevent users from ever testing these apps in new versions of Wine, or trying to find workarounds? I do a fair amount of head-bashing myself, and I would find such a message patronizing and intrusive.
Agreed. Wine doesn't make efforts to babysit users for most other things, I don't see why this should be any different.
Also consider that if such a workaround were to go into wine, that code may long outlive the 'affected apps', and the list would quickly grow out of date.
I suppose if a packager wanted to do something like this for their distro I wouldn't complain too much, unless users started asking about it in #winehq/the forums. But this _should not_ go into vanilla wine.
-- -Austin
The dialog could suggest upgrading Wine, that would prevent the affected app list from getting out of date. Damjan
On Thu, Sep 9, 2010 at 6:12 PM, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote:
On Thu, Sep 9, 2010 at 5:47 PM, Austin English <austinenglish(a)gmail.com> wrote:
On Thu, Sep 9, 2010 at 8:34 AM, Rosanne DiMesio <dimesio(a)earthlink.net> wrote:
On Thu, 9 Sep 2010 00:59:32 -0700 Dan Kegel <dank(a)kegel.com> wrote:
Watching Twitter, one fairly frequently seems people trying and failing to run iTunes 10 and the like in Wine.
Should we let them bash their heads against the wall like that?
Maybe we should detect the top ten apps that don't work with Wine, and put up a warning dialog saying they are known not to work, and people shouldn't try. (Kind of like what Windows 7 does when you do something dangerous, e.g. try to look at the contents of drive C:.)
Do you really want to prevent users from ever testing these apps in new versions of Wine, or trying to find workarounds? I do a fair amount of head-bashing myself, and I would find such a message patronizing and intrusive.
Agreed. Wine doesn't make efforts to babysit users for most other things, I don't see why this should be any different.
Also consider that if such a workaround were to go into wine, that code may long outlive the 'affected apps', and the list would quickly grow out of date.
I suppose if a packager wanted to do something like this for their distro I wouldn't complain too much, unless users started asking about it in #winehq/the forums. But this _should not_ go into vanilla wine.
-- -Austin
The dialog could suggest upgrading Wine, that would prevent the affected app list from getting out of date.
Damjan
If we would want any application database stuff, perhaps appdb would be the place to store information like this. There should come some way to extract this information to an XML file or whatever format periodically. It could be packaged with a wine build or optionally downloaded when you run Wine or so. Roderick
Perhaps making a hash based on app name and version in the appdb, and then have wine reading the hash from the app to check against the appdb. If anyone uses Fedora, their ABRT tool generates hashes for different bugs and then searches their bugzilla before submitting the crash dump, to find if a report is already generated. If the report is already in bugz, then it appends to that bug.We could do something similar, but check against the appdb, and notify the user.. Maybe there could be a separate builtin app (like notepad and explorer) to read the appdb and check ratings, and allow access to the appdb without having to fire up the web browser? Thanks Tom On Thu, Sep 9, 2010 at 2:15 PM, Roderick Colenbrander < thunderbird2k(a)gmail.com> wrote:
On Thu, Sep 9, 2010 at 6:12 PM, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote:
On Thu, Sep 9, 2010 at 5:47 PM, Austin English <austinenglish(a)gmail.com> wrote:
On Thu, Sep 9, 2010 at 8:34 AM, Rosanne DiMesio <dimesio(a)earthlink.net> wrote:
On Thu, 9 Sep 2010 00:59:32 -0700 Dan Kegel <dank(a)kegel.com> wrote:
Watching Twitter, one fairly frequently seems people trying and failing to run iTunes 10 and the like in Wine.
Should we let them bash their heads against the wall like that?
Maybe we should detect the top ten apps that don't work with Wine, and put up a warning dialog saying they are known not to work, and people shouldn't try. (Kind of like what Windows 7 does when you do something dangerous, e.g. try to look at the contents of drive C:.)
Do you really want to prevent users from ever testing these apps in new versions of Wine, or trying to find workarounds? I do a fair amount of head-bashing myself, and I would find such a message patronizing and intrusive.
Agreed. Wine doesn't make efforts to babysit users for most other things, I don't see why this should be any different.
Also consider that if such a workaround were to go into wine, that code may long outlive the 'affected apps', and the list would quickly grow out of date.
I suppose if a packager wanted to do something like this for their distro I wouldn't complain too much, unless users started asking about it in #winehq/the forums. But this _should not_ go into vanilla wine.
-- -Austin
The dialog could suggest upgrading Wine, that would prevent the affected app list from getting out of date.
Damjan
If we would want any application database stuff, perhaps appdb would be the place to store information like this. There should come some way to extract this information to an XML file or whatever format periodically. It could be packaged with a wine build or optionally downloaded when you run Wine or so.
Roderick
Scott wrote:
This would be relatively simple to implement, and would even be doable with a shell script outside of Wine. Just md5sum the .exe, compare it with a blacklist, pop the warning if so, and if not pass it to the normal Wine process.
You'd probably want to sha1sum only the first megabyte or so, since getting the checksum of a gigabyte executable would really slow things down. And you might want to do it only for files that are doubleclicked on, i.e. in the desktop integration, rather than messing with the real wine. - Dan
On 9 September 2010 15:53, Dan Kegel <dank(a)kegel.com> wrote:
Scott wrote:
This would be relatively simple to implement, and would even be doable with a shell script outside of Wine. Just md5sum the .exe, compare it with a blacklist, pop the warning if so, and if not pass it to the normal Wine process.
You'd probably want to sha1sum only the first megabyte or so, since getting the checksum of a gigabyte executable would really slow things down.
And you might want to do it only for files that are doubleclicked on, i.e. in the desktop integration, rather than messing with the real wine. - Dan
I brought up a long time ago the idea of having something like this that checked the current rating in the appdb. So exe files are associated with the appdb entry and double-clicking would say something like: "This Windows application is rated as Bronze and may not run correctly" or something.
Luke.
On Thu, Sep 9, 2010 at 8:06 AM, Luke Benstead <kazade(a)gmail.com> wrote:
I brought up a long time ago the idea of having something like this that checked the current rating in the appdb. So exe files are associated with the appdb entry and double-clicking would say something like: "This Windows application is rated as Bronze and may not run correctly" or something.
Yeah... well, it's hard to do this right, so it might only be worth doing it for the apps that cause the most grumbling about Wine on the web. - Dan
On 09/09/2010 08:06 AM, Luke Benstead wrote:
On 9 September 2010 15:53, Dan Kegel <dank(a)kegel.com <mailto:dank(a)kegel.com>> wrote:
Scott wrote: > This would be relatively simple to implement, and would even > be doable with a shell script outside of Wine. Just md5sum > the .exe, compare it with a blacklist, pop the warning if so, > and if not pass it to the normal Wine process.
You'd probably want to sha1sum only the first megabyte or so, since getting the checksum of a gigabyte executable would really slow things down.
And you might want to do it only for files that are doubleclicked on, i.e. in the desktop integration, rather than messing with the real wine. - Dan
I brought up a long time ago the idea of having something like this that checked the current rating in the appdb. So exe files are associated with the appdb entry and double-clicking would say something like: "This Windows application is rated as Bronze and may not run correctly" or something.
This idea has come up many times, really. In the past nothing's been done because 1) Wine was changing fast, and so were the apps that it would work with 2) It'd be more productive to spend time on making apps work anyway (a similar argument can be made for AppDB in general) However this is clearly not a complete argument, as I'd say it's worth having AppDB and getting warnings about garbage apps you're about to run is just AppDB in a far more convenient fashion. I agree with what Austen said about doing this in the packaging layer - it seems like the perfect thing for a winezeug project with packagers putting the script as a front end to Wine. We could hit 90% with a very primitive implementation (such as looking up a static list of bad filenames). Plus, we'd need someone to make the actual interface, which I believe is another reason why it hasn't gotten done in the past. But maybe I can fill that gap ;) Thanks, Scott Ritchie
it would be cool if a dialog like this will also show the howto (or other notes) from the appdb, it will be helpful for new users. 2010/9/10 Scott Ritchie <scott(a)open-vote.org>:
On 09/09/2010 08:06 AM, Luke Benstead wrote:
On 9 September 2010 15:53, Dan Kegel <dank(a)kegel.com <mailto:dank(a)kegel.com>> wrote:
Scott wrote: > This would be relatively simple to implement, and would even > be doable with a shell script outside of Wine. Just md5sum > the .exe, compare it with a blacklist, pop the warning if so, > and if not pass it to the normal Wine process.
You'd probably want to sha1sum only the first megabyte or so, since getting the checksum of a gigabyte executable would really slow things down.
And you might want to do it only for files that are doubleclicked on, i.e. in the desktop integration, rather than messing with the real wine. - Dan
I brought up a long time ago the idea of having something like this that checked the current rating in the appdb. So exe files are associated with the appdb entry and double-clicking would say something like: "This Windows application is rated as Bronze and may not run correctly" or something.
This idea has come up many times, really. In the past nothing's been done because
1) Wine was changing fast, and so were the apps that it would work with 2) It'd be more productive to spend time on making apps work anyway (a similar argument can be made for AppDB in general)
However this is clearly not a complete argument, as I'd say it's worth having AppDB and getting warnings about garbage apps you're about to run is just AppDB in a far more convenient fashion.
I agree with what Austen said about doing this in the packaging layer - it seems like the perfect thing for a winezeug project with packagers putting the script as a front end to Wine. We could hit 90% with a very primitive implementation (such as looking up a static list of bad filenames).
Plus, we'd need someone to make the actual interface, which I believe is another reason why it hasn't gotten done in the past. But maybe I can fill that gap ;)
Thanks, Scott Ritchie
--
אלעד
On 10 September 2010 21:47, אלעד <el.il(a)doom.co.il> wrote:
it would be cool if a dialog like this will also show the howto (or other notes) from the appdb, it will be helpful for new users.
How many times does this have to come up before people finally realise it's not a good idea? 1) Any form of automated AppDB processing is problematic, even dangerous due to the variable quality of content. 2) Any additional dependence on internet connections is a bad idea. 3) All work and little benefit. 4) Other forms of application-specific behaviours are rejected by Wine devs (e.g., app-specific Direct3D processing). My main issue now is that Dan appears to be taking statistics from Twitter in the same way that major companies take idiots for their usability studies. "Start the File Manager" "Where's the Start button?" "Press any key to continue" "Where's the Any key? I see Esk, Ctarl, and Pig Up" Wine cannot afford to hand-hold users too much. Let Codeweavers worry about this for Crossover.
As Austin said, if this script has a place, it's somewhere in the middle between upstream and downstream. On Fri, Sep 10, 2010 at 2:04 PM, Ben Klein <shacklein(a)gmail.com> wrote:
My main issue now is that Dan appears to be taking statistics from Twitter in the same way that major companies take idiots for their usability studies.
This really bothers me. Forwarding anecdotic tweets != taking statistics. NOT forwarding anecdotic tweets == dismissing potentially-good feedback because "users are idiots". -- J. Leclanche
On Fri, Sep 10, 2010 at 7:04 AM, Ben Klein <shacklein(a)gmail.com> wrote:
Wine cannot afford to hand-hold users too much. Let Codeweavers worry about this for Crossover.
Yes we can afford to hold users hands. In fact, we should be holding users hands.
From a usability standpoint, Linux sucks. Fortunately, it's sucked for so long most of us can be accepting of it. However, Wine specifically targets a set of users who are transitioning from Windows. The first thing they do when they need to run Microsoft Office is run to Google and type in "Microsoft Office Linux". The choices that come up direct them to try out Wine. So here they are, trying to figure out Linux package management works, trying to download and install Wine, and then they have to do some kind of magic foo like "winetricks msxml6 gdiplus gecko vcrun2005 ie6" that probably makes no sense to them. So, I think we should be helping those users and making things as easy as we can for them. Things should Just Work. But, if something fails, it should fail gracefully and not in some mysterious I-think-it's-broken-but-maybe-not-WTF-is-going-on sort of way. If we can preempt those errors, I think it's a good thing.
Since we tend to never hear from people who agree with ideas, I'll just chime in to say I think this is a good idea. Up to you guys at what level this should be handled, but I do think that Scott and Austin's idea to handle this with a wrapper at the packaging level with just a static list of names solves most of this problem. -Brian
Hello On 9 September 2010 08:59, Dan Kegel <dank(a)kegel.com> wrote:
Watching Twitter, one fairly frequently seems people trying and failing to run iTunes 10 and the like in Wine.
Should we let them bash their heads against the wall like that?
Maybe we should detect the top ten apps that don't work with Wine, and put up a warning dialog saying they are known not to work, and people shouldn't try. (Kind of like what Windows 7 does when you do something dangerous, e.g. try to look at the contents of drive C:.)
Forgive me if I am posting to the wrong mailing list. I was going to post my question in the Users mailing list/forum before I came across this thread. An Introduction I use SUSE Linux 10.3 and I downloaded Wine version 1.3.1 to enable me to use the Watchtower Library (I am a Jehovah's Witness.) I am a progammer and have taken delivery of an Apple iPad. Unfortunately my iMac G4 has packed up (it won't boot up) so my relevant question is what process would I have to adopt to be able to help myself and others to run iTunes under Wine? Admittedly, I would need to use the iTunes store and maybe this could be a problem. I have noted the comments in the AppDB relating to iTunes version 9.2.1. I would appreciate your comments on whether this is advisable etc. TIA Michael -- michaelrf.hunter at gmail dot com
On Fri, Sep 10, 2010 at 10:55 AM, Michael Hunter <michaelrf.hunter(a)gmail.com> wrote:
what process would I have to adopt to be able to help myself and others to run iTunes under Wine? Admittedly, I would need to use the iTunes store and maybe this could be a problem. I have noted the comments in the AppDB relating to iTunes version 9.2.1. I would appreciate your comments on whether this is advisable etc
That's the point of this thread - it's not advisable for the average user to try iTunes newer than version 7 or so. And even then, IIRC, it won't talk to newer iPods, and it's slow. Anyone who wants can try fixing the related wine bugs, but they're hard, not something beginners can help with.
participants (15)
-
Austin English -
Ben Klein -
Brian Vincent -
Damjan Jovanovic -
Dan Kegel -
Jerome Leclanche -
Luke Benstead -
Michael Hunter -
Octavian Voicu -
Roderick Colenbrander -
Rosanne DiMesio -
Scott Ritchie -
Tom Spear -
Tom Wickline -
אלעד