Implications for Wine from the Ubuntu Developer Summit

[Scott Ritchie]

Ben Klein wrote:
> 2009/6/2 Scott Ritchie <scott at open-vote.org>:
>> 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.
> 
> As far as I know, this is not possible for Wine (without massive
> latency issues caused by overbuffering in Wine itself) due to the fact
> that Wine has to make DirectSound apps happy. It's also not very
> consoling from this Pulseaudio expert that they don't seem to see a
> problem with the ALSA layer on their end - "it's the apps that need to
> be fixed". Wasn't the point of Pulse that you could use libasound/OSS
> apps without modification? :)
> 

I'll admit I'm a bit over my head here, but I'd be surprised to find out
if a typical DirectSound App on Windows was really as low-latency as we
seem to be grabbing for.  Windows doesn't generally grant applications
direct control over the audio hardware either.

>> 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
> 
> PulseAudio will *always* have more latency than ALSA. This has nothing
> to do with kernel configurations, just that using a
> CONFIG_NO_HZ/CONFIG_HZ_1000 (or whatever it is) kernel from the -rt
> tree makes the latency issue less severe. New kernel won't fix Wine +
> Pulse problem.
> 

Going from 200 to something like 50 ms latency will solve about 90% of
the problem though.  This is doable with kernel changes alone (some of
the shipping kernels are indeed that bad).

>> 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
> 
> Something tells me this isn't going to happen soon in Wine :D
> 

It would make a good summer of code project I bet. I agree there are
probably more important things to do, though it's hard to recognize
what's an important feature when talking about potential rather than
current users.  Potentially, Wine could be very valuable as a general
office tool, where printing is much more important.

>> 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 has been discussed before on -devel. I believe the consensus was
> "no, we don't want Wine to respect execute bit" (though I'd still like
> it to respect noexec mount option if possible).
> 
> The biggest problem with the GUI proposal for confirming execution of
> non-+x files as far as I can see is how do we handle a win32 app
> launching a non-+x app (as so many installers would be likely to do)?

That's simple; we let it.  The execute bit is an indicator of trust in
an app - once you've trusted it to run then it can do whatever it wants,
so we might as well let it run other apps.  Wine's pretty good about
marking installed apps as +x anyway; this is really mostly an issue with
freshly downloaded .exes (note that .exe's on CD drives are going to be
assumed +x anyway).

> Should that produce a new dialog (thus irritating the user to all
> kinds of heck) or should one confirmation per user-controlled app
> launch be enough (thus not providing any real benefit)?

I don't see how it's "not any real benefit" when the whole point is to
prevent accidental launching.  You see the prompt the first time, you
dismiss it if you didn't mean to run something, and you let it go if you
did.  In the meantime it's scanned for viruses.

Thanks,
Scott Ritchie