2009/2/10 Francois Gouget fgouget@free.fr:
On Tue, 10 Feb 2009, Ben Klein wrote: [...]
Application tried to create a window, but no driver could be loaded. Make sure that your X server is running and that $DISPLAY is set correctly.
Interesting. xauth problem. Again, I'd be surprised if this happened with sudo. Not so surprised if it happened with "su -".
X access will very often be broken after a sudo or an su (e.g. Debian). In fact I believe it will only work on distributions which install special PAM packages. For all others you should use gksu, kdesu or sux.
I'm on Debian and I don't have trouble with X access when using su. "su -" is another matter entirely.
I don't know about X access with sudo (because I've strictly restricted my sudo to only run certain commands. I like my root user :) ), but I'd imagine it'd work because $HOME is not overridden, so the sudo'd program would be using the original user's ~/.xauth file. Also, $DISPLAY would be set correctly.
2009/2/11 Vitaliy Margolen wine-devel@kievinfo.com:
Alexandre Julliard wrote:
Vitaliy Margolen wine-devel@kievinfo.com writes:
vitaliy@dragon:~ $export WINEPREFIX=~/.wine-root vitaliy@dragon:~ $sudo wine winecfg root's password: wine: created the configuration directory '/root/.wine'
As you can see it's creating a new prefix under /root, so it's not messing up the user's prefix. That's perfectly fine.
That part worked you are correct.
However X11 part didn't (missing $DISPLAY). And even if $DISPLAY would be defined in this case all programs will be installed into root's env not user's. No menu entries, no desktop links no visible installed programs - big problem for noob users "where did my stuff go"?
This is not a problem with Wine, this is OpenSUSE breaking the environment when sudo is called. Remember, Wine is not the only X11 app out there. Others will need $DISPLAY working!
Creating the wineprefix in root's home directory is expected behaviour if $HOME is being overridden by preference in /etc/sudoers. Take it up with the OpenSUSE guys if you don't like it.
2009/2/11 Alexandre Julliard julliard@winehq.org:
Austin English austinenglish@gmail.com writes:
On Tue, Feb 10, 2009 at 10:44 AM, Alexandre Julliard julliard@winehq.org wrote:
No, a warning that will get drowned in a bunch of other fixmes is not useful.
Probably not, but I've seen a lot of newbies run "sudo winecfg" because winecfg is a config tool, so they assume that it needs to be run by root. In these cases, a message on console would likely be visible, but I wouldn't be surprised if 90% of them still ignore it. "Where's my pretty GUI? Why do I have to read all this boring text?", that sort of thing.
We could make it a popup warning, again, only on first run.
No, warning message boxes are just as useless, users have been conditioned by MS to click through without reading.
Not just useless, but very, very annoying :) Plenty of times, I've started an app, gone to do some typing in another app, then a popup appears as I'm typing which steals focus and I end up hitting "OK" on it without being able to read it.
Also, if we do think about a message box, we have to think about how to deliver it. It's been talked about before, and it can't be a Wine dialog due to the amount of initialisation required before that point (in particular, creating the wineprefix with wineboot). What options does that leave us? Dialogs that depend on GTK, QT or KDE backends? Choosing the "wrong one" here could annoy a lot of people, and for proper integration it'd have to be chosen on a per-system basis, thus supporting each method.
What about xmessage? Two words: it's ugly. It'd likely annoy new users who suddenly see this ugly, old-styled dialog box in the middle of their fancy new system, and people would probably ask why we can't use something that better integrates with <insert DE here>.
If you really want to prevent users from running as root you have to refuse to create the prefix and abort, and then make them jump through hoops to create it manually, by running wineboot explicitly or something like that.
This is kinda what I've been getting at with earlier posts. Should a warning be a show-stopper? If so, this is a messy and unfriendly way of doing things. Let's not be Windows Vista-style UAC here, let's remember we're working on a Unix (or at least Unix-like) platform.