Hi!
passwd(1) now disallow changing a password via PAM. Why? Is there some
hidden reason like a security one or something I missed?
Here is code:
/* check where the user's from */
switch (pwd-pw_fields _PWF_SOURCE) {
case _PWF_FILES:
fprintf(stderr,
on 19/03/2007 12:24 Pyun YongHyeon said the following:
Unlike other MCP hardwares, MCP61/MCP65/MCP67 stores ethernet address
in-order. nve(4)/nfe(4) should not swap ethernet address on these
hardwares. Peer Chen at NVIDIA and Shigeaki Tagashira sent me patches
to the issue and I've updated
On Fri, Mar 16, 2007 at 06:55:00PM +0200, Andriy Gapon wrote:
I am wondering what is the purpose of the following pieces of code in
if_nve.c:
/* ... nve_attach ... */
/* MAC is loaded backwards into h/w reg */
sc-hwapi-pfnGetNodeAddress(sc-hwapi-pADCX,
Garrett Cooper wrote:
I was recently grepping a directory and outputting to a file located in
the same directory as follows:
grep -ri {key} * {key}.found
The thing is that grep kept on feeding off of the {key}.found file and
eventually ate up all the free space on the device
I compiled the latest -current, with the latest nfe, and I got a slight
regression :-)
...
nfe0: NVIDIA nForce 430 MCP12 Networking Adapter port 0xdc00-0xdc07 mem
0xfe02c000-0xfe02cfff irq 21 at device 20.0 on pci0
nfe0: Ethernet address: 50:71:a9:f3:18:00
nfe0: MII without any phy!
kernel trap
I have a related question - it would be great if someone could help me. Let's
say there are multiple system scope pthreads running on an SMP system. Is
there a chance that if a pthread holding a spinlock is scheduled out (due to a
scheduling decision etc.) then other pthreads will be starved.
On Mon, 19 Mar 2007, Peter Holmes wrote:
I have a related question - it would be great if someone could help me. Let's
say there are multiple system scope pthreads running on an SMP system. Is
there a chance that if a pthread holding a spinlock is scheduled out (due to a
scheduling decision
* Ed Schouten [EMAIL PROTECTED] wrote:
When all the PR's are closed, I guess most people can live without
COMPAT_43TTY as well. Maybe we should add a permanent #warning to
sgtty.h to warn people that they shouldn't use it and that it depends
on COMPAT_43TTY?
This should do the trick:
%%%
---
Hello,
I have:
ldd /usr/local/sbin/clamd
/usr/local/sbin/clamd:
libclamav.so.2 = /usr/local/lib/libclamav.so.2 (0x80063e000)
libiconv.so.3 = /usr/local/lib/libiconv.so.3 (0x8007a8000)
libz.so.3 = /lib/libz.so.3 (0x800999000)
libbz2.so.2 = /usr/lib/libbz2.so.2
On Mon, Mar 19, 2007 at 02:04:58PM -0400, Daniel Eischen wrote:
No, especially if the threads hold other locks.
I have no idea why POSIX added spinlocks. I don't
see why anyone would want to use them.
Given that it is part of the realtime extensions, it makes sense. On
those systems you
On Mon, 19 Mar 2007, Joerg Sonnenberger wrote:
On Mon, Mar 19, 2007 at 02:04:58PM -0400, Daniel Eischen wrote:
No, especially if the threads hold other locks.
I have no idea why POSIX added spinlocks. I don't
see why anyone would want to use them.
Given that it is part of the realtime
On Mon, Mar 19, 2007 at 05:53:10PM +0200, Danny Braniss wrote:
I compiled the latest -current, with the latest nfe, and I got a slight
regression :-)
...
nfe0: NVIDIA nForce 430 MCP12 Networking Adapter port 0xdc00-0xdc07 mem
0xfe02c000-0xfe02cfff irq 21 at device 20.0 on pci0
nfe0:
12 matches
Mail list logo
