Mike Hearn wrote:
Other solution is just to detect this and ask the user to rerun Wine as root. I don't think that'd be a big deal.
But then that brings up the issue of users not being able to run wine merely because they don't have root access, i.e. users on a Linux system in a business environment, or remote X/telnet access on a server with wine (for various reasons).
These people probably wouldn't be running scheduling sensitive tasks.
The idea of having to run under root was one of the ones why people avoid SVGAlib nowadays, and setuid/root will be a deep security risk considering what kind of apps we're looking at here. If we say, run notepad, we have a root editor application -- capable of messing with config files on the Linux setup -- something that the Linux admin might not want.
You can make Wine suid root and then sandbox it back down to standard user level privs + scheduling using SELinux, so it'd only be a security "problem" for a short while.
Given that we know of no Windows apps self-aware enough to escape the emulation I don't even see what security problems it can cause on home machines where the user has root access anyway. I guess if you got owned via Internet Explorer or something it would give attackers access to your configuration files but the chances of this happening and being taken advantage of are tiny.
I wouldn't trust it. An app just misbehaving can trash important parts of your filesystem. Suid root is just a bad idea, windows being linux aware or not. Just for mild amusement I think someone being funky got a windows virus to work under wine if I recall correctly.
If this is implemented, shouldn't this be a warning, not a forced thing? So that a normal user could (try and) run wine without root access? And I presume that this would be 2.6 specific detection - otherwise, there's not really a need (since Wine worked OK under 2.4 and such). We could say something like: "Wine has dectected that you are running Wine as a normal user under Linux kernel 2.6+. Due to changes in the scheduling mechanism in 2.6, which includes preempting and a change in the way process priorities are handled, Wine may not work properly, or different parts may work at different speeds, causing desyncronization of your application and/or it's components. You are suggested to <(run wine as root) or (downgrade and use a (2.4 kernel) AND/OR <supported kernels list>) or (list other workaround information)>."
Well, ideally it'd be only displayed when we detected a mismatch between the apps requirements and the underlying kernel scheduling. Which may not even exist: we haven't *proven* anything yet, just thrown theories around. Unfortunately the people most qualified to diagnose the problem are all as much in the dark as we are :(
You should not renice any user applications -nice. The only solution is to run the less important ones +nice. Also, if you renice something from wine to better priority than X you will almost certainly have worse behaviour, not better, because X is almost always seen as consuming as much cpu as you give it thus being lower priority than a wine app that does any sleeping. Feel free to try it; you'll see performance gets worse as the nice value is less nice than X. Recall this email thread started with nice+19 being a workaround, not the other way around.
Random point: the wording of that warning is terrible I'm afraid :) There's no way we could ever throw such a complex message in the users face, nobody would understand it! A much better way to word such a message would be:
"In order for this program to run correctly, you must run Wine with root priviledges. The program will proceed but you may notice audio stuttering or performance problems."
Even that's not ideal. It requires the user to:
a) Understand the concept of root == administrator user that should not normally be used, which is a non obvious mapping. It's one of those things you just "have to know", and we're trying to cut the number of these things as much as possible.
b) Understand what Wine is - obviously we can't get away from this entirely but long term I'd like to see Wine become just another Linux subsystem that does its job so well the user doesn't ever notice it
c) Understand *how* to run Wine with root privs. If you just su to root and run it, you can't start your app as you're now running with a different virtual Windows drive and registry. It's really not obvious how to do this even for experienced Linux users (answer, set WINEPREFIX)
Anyway. That's todays usability lecture over with :)
Agreed. Nonetheless I think this is the wrong approach.
I presume that if someone wanted to get started writing a patch now using any one of these ideas, then we could just test it and see how it does among us, and then if it's okay, submit it, get it through CVS, see what happens, get it through a release if that happens, and then we can finish this debate only when performance issues or something else needs to be done about this.
I think we should get a much clearer idea of what's going wrong here first before trying to write patches or get code into CVS.
Agreed; recall this was not all versions of wine that were proven to be affected.
This will all change as Xorg matures though so we may have to rethink everything. Keith Packard has explained that X that currently uses cpu is doing precisely nothing during that cpu time. It is spinning just waiting for the graphics cards' gpu to do the work. This is ancient behaviour from X that we still have that is done to represent the fact that X is busy and is as far as I'm concerned the single most important change required to improve graphics performance in linux.
Cheers, Con