Implications for Wine from the Ubuntu Developer Summit

Daniel Devine devine at ddevnet.net
Tue Jun 2 01:54:24 CDT 2009


On Tuesday 02 June 2009 11:26:36 Scott Ritchie wrote:
> Hello everyone,
>
> I've just returned from the Ubuntu Developer Summit in Barcelona last
> week.  A lot of interesting stuff that concerns Wine happened there, and
> a lot of applies to every distro.  I'll give a brief summary in this email.
>
> Audio:
>
> First, I talked with a Pulseaudio expert about what we can do to make
> things work better.  He said that if we want good compatibility we will
> need our ALSA stack to use the Pulseaudio safe subset:
> http://0pointer.de/blog/projects/guide-to-sound-apis.html. I've filed a
> metabug tracking this here:
> http://bugs.winehq.org/show_bug.cgi?id=18740.  Use of this unsafe subset
> can cause most problems with stuttering or even complete dropoff.
>
> I'm not completely familiar with how sound works in Wine, but in the
> past I remember that one complaint about PulseAudio over ALSA was
> latency.  Latency issues these days are mostly due to bad kernel
> configurations, which Lennart wrote about here:
> https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-
February/003150
>.html.
>
> In the meantime we should develop for the future using kernels with
> preempt enabled at 1000 HZ.  Currently neither Open SuSE nor Ubuntu 
are
> configured this way, however I know in the case of Ubuntu that this is
> being fixed for next release.  In particular, if you develop on Ubuntu,
> you should either upgrade to Karmic Alphas or install a custom kernel.
> The -rt flavor of the kernel is known to have problems as well.
>
> Printing:
>
> A printing expert from http://openprinting.org says we should output
> .pdf files to cups rather than postscript. .pdf are becoming the
> standard for printers, and apparently they allow some good things that
> postscript does not.  I've filed a bug on this here:
> http://bugs.winehq.org/show_bug.cgi?id=18741
>
> Security and Usability:
>
> The security team thinks we should finally start respecting the execute
> bit - this means removing all MIME handlers for executable code from the
> desktop and replacing them with a single front end for programs lacking
> the execute bit. This front end would notify the user of the problem,
> scan the file for viruses, and then present some information about the
> path towards execution.  It is still undecided whether the program
> should allow execution outright, however from a UI perspective this
> would clearly be more efficient.
>
> This creates a design challenge.  In brief, we have to simultaneously
> manage expectations about Wine, inform the user that there are other
> (preferred) methods for installing software, not patronize them for
> installing a Windows program, tell them we scanned a file for viruses
> but that it may still be unsafe, make it easy to use, and make it hard
> to use accidentally.
>
> After input from the community and discussion with other designers, I
> believe I have some good ideas for how to handle these challenges.  The
> Canonical design team has agreed to integrate the UI extensions I've
> gathered into their weekly user testing, so over the next few months we
> should be getting some real feedback on the merits of various 
approaches
> to this problem. I'll be working more on this personally, and already
> have a good chunk of the specifications and front end code done (thanks
> to some great community help). I will, of course, share it here when
> it's in a usable state.
>
> As far as we, as an upstream, are concerned, there's not much to change
> in Wine itself other than to keep making it work better and fix bugs.
> If I had to name one in particular, I'd have to say the "unclean removal
> of applications menu" entries is a particularly confusing issue for users.
>
> What I'm doing:
>
> Over the next few months I'm going to be working rather hard on the
> Karmic Wine Integration spec that I lead at the Summit:
> https://wiki.ubuntu.com/karmic-wine-integration.  I'm still drafting the
> spec based on my notes and discussion, but at this point I have a very
> good idea of what I want to do.
>
> Most of the code involved is directly relevant to the Wine user, however
> almost none of it needs to go into Wine itself other than some icons.
> At this point it's mostly python scripts, modifications of other python
> programs, and Glade dialogs.  I may set up a BZR/Git repository of the
> various bits once they start turning into actual packages (which I'll
> also be doing).
>
> Anyway, keep your eyes peeled, the next wave of distro releases are
> going to be very slick.
>
> Thanks,
> Scott Ritchie

Great work so far Scott. 

In regards to respecting the execute bit, I think that there really has to be 
a lot of thought put into the UI design so that the users respect the 
security. We don't want a Windows Vista/7 UAC type complete and utter 
failure. A dialog reminiscent of UAC will trigger the mindless "I wish this 
damn thing would stop popping up" *click* *click* *click* 
Encouraging this type of behavior could be disastrous because it offers a 
way for malicious people to EASILY engineer an attack on Linux. 

No doubt you have heard the jokes before about getting viruses to run on 
Linux and how the virus would need to come with instructions to launch the 
script/executable... though if the user wants to run CutePuppyPictures.exe 
you can't really stop them. Users really like to see cute puppies, and if that 
means installing something then they will.
 
Hopefully we can find a way to make them stop for just a second and think.

--Daniel Devine



More information about the wine-devel mailing list