Wine Traffic #269 For 8 Apr 2005

Joe: OK, that's how you got started. What was your first involvement with an open source project?

Miguel: I cannot remember. I think it was that I was contributing the routines that ran in route, without any port of Wine, I think. Then I worked on Midnight Commander.

Joe: That was your first big splash.

Miguel: I think I was working on Wine, turning Wine into a library, back in the day. No, it wasn't a big splash back in the day. It was just a little tool that I wrote, that was it. It was a tiny tool.

Joe: Midnight Commander?

Miguel: Yeah, but that was in 1992.

Mapping Win32 thread priority levels to Linux nice levels is fairly trivial, but convincing kernel developers to allow unprivileged user-space programs to control thread priorities is the big problem. The last time a discussion like this came up, we (Wine developers and Cedega developers) requested a way of changing a thread's relative priority within a process (without affecting the overall CPU time the process gets). This should be a good compromise between meeting applications' needs and preventing unprivileged applications from freezing the computer. AFAIK, this hasn't been implemented yet.

CAP_SYS_NICE gives you:

• Allow raising priority and setting priority on other (different UID) processes
• Allow use of FIFO and round-robin (realtime) scheduling on own processes and setting the scheduling algorithm used by another process.

wineserver would need to be a setuid program but it could set CAP_SYS_NICE at startup and immediately reduce it's privileges back to normal.

There are a number of problems:

1. I don't think that will work yet as the server process needs to have the same user ID as the client processes.
2. setuid binaries make sysadmins nervous and would require a security audit by us. Yes, they don't need to make it setuid, but then the people who do could run their programs as root anyway.
3. setuid programs are a nasty hack that work around limitation in the granularity of security in the kernel.
4. This approach won't generalize for other apps on the system that might want to control the relative priority of their threads, such as MPlayer.

Right now, each time I make a modification (even one line) I do a 'make' followed by a 'make install'. Is there a faster way ?

Try to skip the 'make install', and instead run wine from the build directory. eg.

~/src/wine/wine regedit

I make a point of never installing Wine to make sure I don't accidently run an older installed version that didn't get overwritten properly.

You can also just have a script called wine in your path, that does something like

#!/bin/bash
/path/to/wine $*

just check you don't have other files in your path called wine.

A while ago we were debating an initiative named "Wine-Probe"[1] (which would roughly equal "Wine-tasting" in english) on wine-devel that was in the making between Wirtschaftsförderung Region Stuttgart GmbH and us (ITOMIG). Its goal is to make local software vendors aware of the potential business opportunity in a Wine-based port or a Wine/Linux version of their software. It's also designed to be beneficial for the Wine project as a whole, e.g. by providing AppDB entries and success stories.

This is to let you know that we've officially launched the initiative by today. It has already made it into several (german speaking) news sites[2], so I'd say things look promising. We're looking forward to the interest and feedback we'll get in the weeks to come.

• [1] http://www.winehq.com/site?issue=254#WINEprobe%20Initiative
• [2] http://www.golem.de/0504/37335.html (Google translation)
  http://www.pro-linux.de/news/2005/7996.html (Google translation)
  http://www.pc-magazin.de/common/nws/einemeldung.php?id=37335 (Google translation)

Last year's raving success (I exchanged keys with Marcus) gives appetite for more.

So, if you always wanted to have a PGP key that most of the free software will know [1]. If you wanted to be able to carry out encrypted secure conversations online. Or if you just want a chance to brag about what well connected key you have [2].

We will (try) to hold a PGP key signing party at wineconf this year. In order to participate, it is positively absolutely necessary that you:

1. Have a PGP key. You can generate one for yourself using gpg.
2. Send the PGP key finger print to me AT LEAST A WEEK BEFORE THE CONFERENCE. Any later then that, and it is not certain that we'll manage to get your key on the printed piece of paper that is necessary for carrying out the party.
3. Bring a copy you can trust to wineconf, to make sure other people are really signing your key (i.e. - that I'm not pulling anybody's leg).
4. Bring an identifying ID to wineconf. Two is preferable. Passport or a driver license in a language people can read. If you can only bring one, a passport is definitely preferable.

The full details of what a key signing party is, why are the procedures as they are, and what's so important about *not* signing the keys with your laptop at the party can be found at http://www.cryptnet.net/fdp/crypto/gpg-party.html

Note: No aliases on PGP keys. If your PGP key says "lord master of compiler optimization", then your passport had better say the same or no one will be able to sign your key.

[1] My key is signed by RMS himself (http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xCDBDBCE2). This means that any key that I sign is just two keys away from the very inventor of free software.
[2] See [1]

My mistake. I'm going to need both the finger print AND the actual key. Also, if you DON'T want the key published to a key server (I use http://pgp.mit.edu), please let me know well in advance. Obviously, your key will be published to all the people present at the key party. If your name's not there on your email headers, include it in the body. The name must be the same as appears on your formal IDs.

The purpose of a pgp signing party is to establish a link between your virtual identity (your key) and your real one (as verified by an ID). For that reason it is impossible to participate by proxy, or under an alias.