Hello

Excuse my ignorance, but I am new to NetBSD-current.


A week ago I switched my main computer from freebsd-stable to
NetBSD-current. I have noticed the following things:

galeon crashes more often now
   Might be related to the version of mozilla that it is built together
   with. I think the galeon I used in freebsd was using mozilla 1.0 and
   now it is using mozilla 1.1.

ogg123 stops when resizing windows
   I am using fvwm2. The problem goes away if ogg123 is started with the
   -q switch. I just saw the same problem on freebsd-current on another
   machine. Don't know why it happens. A bird sang to me that this does
   not happen with the sawfish window manager. But who wants to use
   that over fvwm2? ;-)

ogg123 output buffer keeps dropping to zero
   This appears to be pthread related. If I use PTL2 this problem goes
   away (setenv CC ptlgcc ; make PTHREAD_TYPE=PTL).

xmms gui hangs
   Also pthread related. Tried various things but.. nah.

No DRI support
   I think this is the reason why movies are not played smoothly in
   mplayer and ogle. Or perhaps it is something else.. A quick look says
   that porting DRI from linux/freebsd is non trivial.. But it would be
   fun to have. Another solution for smooth movies are nice -20 on the X
   server. Or perhaps a faster computer.

When building several pkgsrc's at the same time using the locking
mechanism, two different make's can start to install the same software
package. (not really a current-users thing)
   I am not sure if this is a problem, but it made me nervous. If I
   started two different pkgsrc 'make install' and they both depended
   upon foobar, one of them would take the lock and start to build
   foobar. Then the other sleeps on that lock. When the first is
   done building foobar, it releases the lock and starts to install
   foobar. This releases the other process which also starts to install
   foobar..


When using PTL2 together with ogg123 this was printed in the xterm every
time it switched song:
pthread_mutex_unlock: WARNING!: thread 1 tries to unlock a mutex (0x80542c0) that is owned by thread 0
Hmmm.. Ah, well, thread programming is hard... :-)

Regarding pthreads, what is the pthreads in the nathan_sa branch based
upon?


Best regards,

	Lars