On Fri, 2003-09-19 at 02:02, M. Warner Losh wrote:
Why would you want to package sbin? Where do you see this work going?
What problems do you think this will solve? Doing things a top level
directory at a time isn't very interesting, but since it looks like a
demo, perhaps you could sketch
On Fri, 2003-09-19 at 02:10, M. Warner Losh wrote:
P.S. How do you handle the packlist generation? The ports system
doesn't automatically generate these things, as far as I can tell, and
I didn't see anything that you've added to do this.
My agenda, if you will, on this is to deal with:
On Thu, 2003-09-18 at 11:25, Alexander Leidinger wrote:
On Wed, 17 Sep 2003 16:27:03 +0100
Paul Richards [EMAIL PROTECTED] wrote:
However, I suspect that a marginally better place to use these would be
in the make distribute target that make release uses. This way, the
files
On Thu, 2003-09-18 at 12:09, Alexander Leidinger wrote:
On Thu, 18 Sep 2003 11:28:31 +0100
Paul Richards [EMAIL PROTECTED] wrote:
We have programs in the ports tree which use our bsd.*.mk
infrastructure. Will there be a problem if such a program gets installed
from ports (will it try
I've got a prototype setup that packages the base tree. It turned out to
be very simple. It needs a lot more polishing and testing but it looks
like this can definitely be made to work with just some tidying up and
re-arranging of our existing make files. I've succesfully created
packages of /sbin
On Wed, 2003-09-17 at 15:45, Mark Murray wrote:
Paul Richards writes:
I've got a prototype setup that packages the base tree. It turned out to
be very simple. It needs a lot more polishing and testing but it looks
like this can definitely be made to work with just some tidying up and
re
On Wed, Sep 17, 2003 at 06:53:41PM +0100, Nik Clayton wrote:
On Wednesday, September 17, 2003, at 04:27 pm, Paul Richards wrote:
I was thinking of adding an option to install so it registers the file
in a plist rather than actually doing the install. A seperate make
plist target could
On Thu, 2003-09-04 at 19:20, Tim Kientzle wrote:
Depends on how you're installing the binary. It has always been
safe to do either of the following:
* Rename the current executable and then install the new one.
* Unlink the current executable and then install the new one.
Many tools
Overwriting a file that's currently executing results in a Text file
busy error.
When did this start happening?
This was something that was fixed way back on FreeBSD but it seems to be
a problem again.
Paul.
intY has scanned this email for all known viruses (www.inty.com)
On Fri, Jun 20, 2003 at 05:16:11PM -0400, Alex Ayala wrote:
Ok, maybe...yes I read what I wrote and didn't quite explain what I really
wanted to say.
I want to setup accounts on my box so users can retrieve emails by accessing
my pop server. Do I need to setup user accounts on my box with
On Wed, Jun 11, 2003 at 09:51:02PM +1000, Anthony Wyatt wrote:
Hi Everyone,
I'm in the process of hand building a FreeBSD 5.1 CURRENT #2 box. I now have a
booting system that I can log onto and use, but my network interface does not work
:-(
I get lots of:
kernel: lnc0: Missed
I've installed a current built last night and job control no longer
works in /bin/sh or /usr/local/bin/zsh, but it does with csh. ctr-c and
ctrl-z are just ignored with both the sh style shells.
--
Tis a wise thing to know what is wanted, wiser still to know when
it has been achieved and wisest
On Wed, Jun 11, 2003 at 11:21:16PM -0400, Andrew Lankford wrote:
Info about my buildworld:
FreeBSD bogushost2 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Wed Jun 11 21:33:34 EDT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARL5KERNEL i386
In addition to my pppoe/adsl connection no longer
On Wed, Jun 11, 2003 at 03:39:33PM +0100, Bruce Cran wrote:
I get this all the time on my FreeBSD 4.8-RELEASE system, which is a P75 with a
lnc NIC. The man page does say this driver is one of the more verbose ones,
and I think the message about no recieve buffer is just that the system cannot
Just got this:
panic: blockable sleep lock (sleep mutex) sellck @
/usr/src/sys/kern/sys_generic.c:1190
Debugger(panic)
Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
db t
Debugger(c029bc34,c02de7a0,c029e847,df12da20,1) at Debugger+0x54
panic(c029e847,c02a9469,c029f08e,c029f065,4a6) at
On Wed, Jun 04, 2003 at 02:43:20PM +0100, Doug Rabson wrote:
On Wed, 2003-06-04 at 14:16, Paul Richards wrote:
On Wed, Jun 04, 2003 at 01:33:46PM +0100, Doug Rabson wrote:
Interfaces actually can be added at runtime. Existing objects (i.e.
objects instantiated before the new interface
On Thu, Jun 05, 2003 at 04:06:16PM +0100, Doug Rabson wrote:
On Thu, 2003-06-05 at 15:51, Paul Richards wrote:
On Wed, Jun 04, 2003 at 02:43:20PM +0100, Doug Rabson wrote:
On Wed, 2003-06-04 at 14:16, Paul Richards wrote:
On Wed, Jun 04, 2003 at 01:33:46PM +0100, Doug Rabson wrote
On Fri, Jun 06, 2003 at 03:01:02AM -0700, Doug Barton wrote:
On Fri, 6 Jun 2003, Brad Knowles wrote:
At 12:09 AM -0700 2003/06/06, Doug Barton wrote:
FYI, for those wondering why I'm not considering BIND 9 for import, please
see http://people.freebsd.org/~dougb/whybind8.html
On Wed, Jun 04, 2003 at 01:33:46PM +0100, Doug Rabson wrote:
Interfaces actually can be added at runtime. Existing objects (i.e.
objects instantiated before the new interface was added) will continue
to work as before. If methods from the new interface are called on old
objects, the default
On Thu, May 29, 2003 at 06:28:26PM -0400, James Tanis wrote:
On Thu, 29 May 2003 17:39:18 -0400 (EDT)
John Baldwin [EMAIL PROTECTED] wrote:
It has been committed. Build rtld with WITH_LIBMAP defined and then
setup a libmap.conf.
--
Alright, I compiled and installed
On Mon, Jun 02, 2003 at 09:04:11AM -0700, Hiten Pandya wrote:
On Mon, Jun 02, 2003 at 08:17:03AM -0700, Terry Lambert wrote:
Hiten Pandya wrote:
My fingers have been itching to do this since the day phk@ planted this
idea in my brain (re: cdevsw initialisations). Basically, it changes
On Tue, Jun 03, 2003 at 08:56:59AM -0600, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Paul Richards [EMAIL PROTECTED] writes:
: You should look at kobj, it's precisely this sort of dynamic
: dispatching that it was designed to support.
Too bad it is a little slow
On Tue, 2003-06-03 at 18:19, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Paul Richards [EMAIL PROTECTED] writes:
: I'm not sure that kobj actually needs to be MP safe if the kobj
: struct is always embedded in a structure at a higher level i.e.
: a use of kobj in say
On Mon, 2003-06-02 at 21:04, Paul Richards wrote:
The tradeoff with using an index into an array is that there'd be a
heavy penalty for growing the array if an extra method didn't fit, but
that would be exceptionally rare and with our present usage we'd never
have that happen.
I'm not sure
On Tue, 2003-06-03 at 22:36, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], John Baldwin writes:
On 02-Jun-2003 Paul Richards wrote:
On Mon, 2003-06-02 at 21:04, Paul Richards wrote:
The tradeoff with using an index into an array is that there'd be a
heavy penalty
On Tue, 2003-06-03 at 22:00, Tobias Roth wrote:
Hi
I still get a
fxp0: device timeout
I get these as well. Is it on irq9 by any chance, along with acpi0 ?
--
Tis a wise thing to know what is wanted, wiser still to know when
it has been achieved and wisest of all to know when it is
On Tue, 2003-06-03 at 23:09, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Paul Richards [EMAIL PROTECTED] writes:
: The possible methods available in an interface are fixed, they're
: defined in the .m files.
No it isn't. One can add additional interfaces at any time
On Tue, 2003-06-03 at 23:17, Tobias Roth wrote:
On Mon, Jun 02, 2003 at 10:59:22PM +0100, Paul Richards wrote:
On Tue, 2003-06-03 at 22:00, Tobias Roth wrote:
fxp0: device timeout
I get these as well. Is it on irq9 by any chance, along with acpi0 ?
No. It's on irc 11 device 8
On Wed, 2003-06-04 at 00:03, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Paul Richards wr
ites:
On Tue, 2003-06-03 at 22:36, Poul-Henning Kamp wrote:
I thought the point in KOBJ was that it was extensible so you could
KLD load stuff which added more methods ?
Not exactly
On Wed, Jun 04, 2003 at 10:01:07AM +0100, Doug Rabson wrote:
On Tuesday 03 June 2003 12:00 am, Paul Richards wrote:
On Tue, 2003-06-03 at 23:09, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Paul Richards [EMAIL PROTECTED] writes:
: The possible methods available
On Wed, Jun 04, 2003 at 12:09:00PM +0100, Doug Rabson wrote:
On Mon, 2003-06-02 at 21:04, Paul Richards wrote:
On Tue, 2003-06-03 at 18:19, M. Warner Losh wrote:
Notice how thread 1's _m gets set based on the results of the kobj
lookup, and we have a race, even if thread1 and thread2
On Wed, May 28, 2003 at 03:39:44PM -0700, Nate Lawson wrote:
On Wed, 28 May 2003, Larry Rosenman wrote:
--On Wednesday, May 28, 2003 03:59:24 -0500 Larry Rosenman
Ok, with today's sources, I still get a page not present panic for
address (0x7) on transistion to battery.
as a followup,
On Wed, May 28, 2003 at 12:04:17PM +0200, Marcin Dalecki wrote:
Harti Brandt wrote:
MDNO no and again no. This would repeat the same design mistake
MDthat is already in Linux. On API level you DO NOT WANT versioning.
MDWhat you really want is: type signature cheking. Like for example
MDdone
On Wed, 2003-05-28 at 17:48, dave wrote:
I don't think anyone is talking about symbol versioning. The issue is
stamping the API at a particular point in time that shows it behaves in
a specified guaranteed way.
The module system has all the hooks to deal with versioning. What's
On Wed, May 28, 2003 at 10:11:19AM +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Guido van Rooij writes:
On Mon, May 26, 2003 at 02:25:08PM +0200, Heiko Schaefer wrote:
Poul gave me the following tip on this list in a mail on Tue, 29 Apr 2003:
Remember to set the
:
ACPI thermal panics my ThinkPad 600X, is anyone
interested in a crash dump analysis?
Cheers,
--
Paul Richards [EMAIL PROTECTED]
FreeBSD Services Ltd
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
On Tue, Jan 14, 2003 at 05:19:36PM -0800, wade wrote:
I tried this, but when the box froze, the keyboard was completely
unresponsive, no numlock, nothing.
No interrupts getting serviced.
I don't know if it's the same bug or not but writing a CD with burncd
lock my box up solid as well.
I'm trying to thrash 5.0 a bit but I've run into some rather more
basic issues right off.
1) I think I'm suffering from the 1GB memory hang problem. I'm
definitely getting the hangs :-) I'll leave this for now since I'll
do some more testing tonight and it's already been raised by someone
else
On Tue, Dec 10, 2002 at 04:02:14PM -0500, Joe Marcus Clarke wrote:
On Tue, 2002-12-10 at 15:48, Kris Kennaway wrote:
On Tue, Dec 10, 2002 at 02:01:08PM +, Paul Richards wrote:
3) The compiler won't build some C++ packages, evolution being the
particular one bothering me
On Sat, 2002-07-06 at 03:46, Garance A Drosihn wrote:
At 3:05 AM +0100 7/6/02, Paul Richards wrote:
Let's start with a premise: No-one running current is using
it for anything other than developing FreeBSD.
This is assumption is too limiting.
It shouldn't be. You're trying to defend
On Sat, 2002-07-06 at 13:29, Ruslan Ermilov wrote:
On Fri, Jul 05, 2002 at 10:45:41AM +0100, Paul Richards wrote:
I think we should add a target to make world that checks for the
existence of an old base install of Perl and removes it if it exists.
As a general principle, if we do
been running
-cruft and not -current at all.
--
Paul Richards|
FreeBSD Services Ltd | Order 4.6 on DVD today!
http://www.freebsd-services.com |
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
should be moved to a compat dir and not deleted.
I do this periodically on my dev box and it does show up issues. I think
it's something we should build into our infrastructure as a step towards
a better known environment for testing -current.
--
Paul Richards |
FreeBSD Services
The recent changes to /usr/include/sys/cdefs.h have broken the build of
XFree86-Server.
The problem is with the _XOPEN_SOURCE macro. At line cdefs.h it's
checked i.e.
#if _XOPEN_SOURCE = 600
but in XFree86 it's defined as
#define _XOPEN_SOURCE
Paul.
To Unsubscribe: send mail to [EMAIL
out
524288 bytes transferred in 0.056482 secs (9282398 bytes/sec)
root@lobster#
atapci0: Intel ICH2 ATA100 controller port 0xb800-0xb80f at device 31.1
on pci0
ad0: 58644MB IBM-DTLA-307060 [119150/16/63] at ata0-master tagged UDMA100
Paul Richards
FreeBSD Services Ltd
http://www.freebsd
to encourage more
developers to run -current but we don't really want users to be running it.
Paul Richards
FreeBSD Services Ltd
http://www.freebsd-services.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
:~$wtf is pola
POLA: principle of least astonishment
husky:~$
I can't see any benefits to having this in the base system.
Make it a port instead.
Paul Richards
FreeBSD Services Ltd
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
.
Neither will I :-)
Paul Richards
FreeBSD Services Ltd
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
There's a strange interaction between su, pam znd zsh.
If you su to an account that has zsh as its shell and then hit ctrl-c it
will kill the shell that you invoked su from.
If you recompile su with -DNOPAM then the problems go away and this doesn't
seem to happen with any other shells either.
My dev box seems to be a bit sick and has been for a day or two.
If anything disk intensive is taking place, and it seems to be particularly
when gzipping/unzipping files, say when building mozilla during the extract
step, things start to crawl and I'm seeing hundreds (500-1200) of
interrupts a
Ian Dowse wrote:
In message [EMAIL PROTECTED], Mike Smith writes:
I don't quite understand Paul's reasoning, though; it's not actually
useful to unload/reload parts of a device's bus attachment without
unloading/reloading all the downstream parts of the driver.
What do you mean by the
"Matthew N. Dodd" wrote:
On Mon, 12 Mar 2001, Mark Murray wrote:
Lots of security minded people what _all_ the interrupt entropy
they can get, and this method gives them that while allowing others
to throttle the harvester back.
Lots of -CURRENT users want to be able to use their
David O'Brien wrote:
We only bumped due to interface changes in the .MAJOR.MINOR days. The
difference is *adding* an interface today does in cause a bump. In the
.MAJOR.MINOR days it would require a bump the MINOR number. In both
days, an incompatible change in an existing interface
Leif Neland wrote:
On Wed, Feb 07, 2001 at 08:23:35PM -0600, Michael C . Wu wrote:
On Thu, Feb 08, 2001 at 01:56:11AM +0100, Leif Neland scribbled:
| It seems pkg_update is only usable when installing from packages, not from
| ports.
Because it is a package update system. If
Will Andrews wrote:
On Wed, Feb 14, 2001 at 03:10:14PM +, Paul Richards wrote:
The problem is that 'make install' in a port doesn't check dependencies
properly, whereas pkg_install does.
Uh, actually, 'make install' does a better job. pkg_install has no
clue about substitute
David O'Brien wrote:
On Tue, Feb 13, 2001 at 04:24:00PM +, Paul RichardsF wrote:
When we dropped minor numbers I had a worry that we'd run into one of
Windows' greatest problems and we have. Applications that are developed
and tested to work with a particular library might not work
a good quote, maybe it should go in fortune.
Paul Richards
FreeBSD Services Ltd
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Mark Murray wrote:
Why does crypt need to be in libc? Not even a significant fraction of
applications need crypt?
Goes for very many libc components. Quite a lot of userland needs libcrypt
(not much as a proportion, but a non-insignificant number).
This runs counter to my gut instinct
"Kenneth D. Merry" wrote:
On Tue, Aug 22, 2000 at 20:43:15 -0400, Laurence Berland wrote:
On a vaguely related topic, after much searching I can't seem to see one
way or the other if we can do a complete bit-by-bit copy of a cd with
either cdrecord or burncd, though it's possible I'm
Alexander Leidinger wrote:
On 23 Aug, Paul Richards wrote:
On a vaguely related topic, after much searching I can't seem to see one
way or the other if we can do a complete bit-by-bit copy of a cd with
either cdrecord or burncd, though it's possible I'm looking in the wrong
place
Jeroen Ruigrok van der Werven wrote:
-On [2822 17:55], Ollivier Robert ([EMAIL PROTECTED]) wrote:
According to Jeroen Ruigrok van der Werven:
Alternatively the sentiment just rose why we couldn't just collapse the
crypt/hash functions of libcrypt into libc.
It would make sense.
David Greenman wrote:
Can you give a reason why we'll have to now start coding defensively
because our arguments to tsleep() are just "advisory" now?
It is not something we "suddenly have to do" it's been The Right Way
even since I first sharpened my teeth on unix kernels many years ago.
David Greenman wrote:
In the particular case of sleeping though, a woken process does need to
check the condition that it slept on because one of the other processes
sleeping on that resource may have had a chance to run first and changed
some state. So as a general rule, you shouldn't
Brian Somers wrote:
In article [EMAIL PROTECTED], Archie Cobbs
[EMAIL PROTECTED] writes
Brian Somers writes:
Also (Mark sits beside me at work), is there anyone else out there
that actually runs FreeBSD-current under VMWare (irrespective of the
host OS) ?
This problem has now
"Brian W. Buchanan" wrote:
On Mon, 15 May 2000, Greg Lehey wrote:
I see this money scheme as an extension of the "finger pointing"
which does nothing to build team spirit.
That depends very much on the way it's taken. At the moment, people
take the pointy hat voluntarily, not
Bill Fumerola wrote:
On Mon, Apr 24, 2000 at 04:46:43AM -0500, Richard Wackerbarth wrote:
From the USER's perspective, anything that requires me to as much as reload
a module/program that I have already installed "breaks" it.
The fact that it is only necessary to recompile it in order
"Brandon D. Valentine" wrote:
On Tue, 25 Apr 2000, Daniel C. Sobral wrote:
Because if we do not provide a STABLE ABI, we WON'T get third-party
(binary only) kernel modules.
I'm very divided in this issue. 4.x has just started, and would be
seriously impaired if no further improvements
Warner Losh wrote:
In message [EMAIL PROTECTED] Alex Zepeda writes:
: Perhaps it's time to implement some sort of versioning in the modules to
: prevent them from being loaded into the incorrect kernel.
In theory that sounds nice, but in -current the kernel ABI changes too
quickly for
Will Andrews wrote:
On Thu, Apr 20, 2000 at 11:56:08AM +0100, Paul Richards wrote:
that rapid developer folks can disable it.
ITYM "rabid". And I kinda resent that.. ;-)
I really did mean rapid, as in those that are installing kernels every
10 mins to test changes.
Though,
"Jordan K. Hubbard" wrote:
But does this also check the kernels ? It was my understanding that
it only did world/release ?
It only does the world/release (and it's the chrooted make release
"world build" which is reported on, not the host system's BTW) but
could easily add a kernel
Kris Kennaway wrote:
On Thu, 23 Mar 2000, Paul Richards wrote:
Because the dlopen() of librsaintl.so fails.
Ok, I give up :-) Why would that happen then ?
I don't know :-)
I stuck a dlerror() in there and the problem is
usr/lib/librsaINTL.so: Undefined symbol "BN_mod_exp
Richard Wendland wrote:
I spent a bit of time analysing these results when I first saw them. I
don't think it has anything to do with the cache, it has to do with how
we write out blocks.
One interesting observation is that for non sync, async or noclusterw
mounts ~8750 I/O operations are
Stephen Hocking-Senior Programmer PGS SPS Perth wrote:
cvs-cur.6183 appeared to fix the crash I reported under disk activity NFS
but another one has reared its face, when using java with tya15 jit, running
the Together java IDE.
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
#1
Alfred Perlstein wrote:
* Poul-Henning Kamp [EMAIL PROTECTED] [000320 11:45] wrote:
In message [EMAIL PROTECTED], Alfred Perlstein writes:
Keeping the currect cluster code is a bad idea, if the drivers were
taught how to traverse the linked list in the buf struct rather
than just
Bruce Evans wrote:
On Sun, 12 Mar 2000, John Polstra wrote:
Sheesh, criticism isn't enough? Now it has to be constructive too? ;-)
I guess it could go into machine/limits.h in the
"!defined(_ANSI_SOURCE)" section. Bruce might have a better idea.
Trying to draw some closure on this
Giorgos Keramidas wrote:
On Sun, Mar 12, 2000 at 05:59:09AM +, Paul Richards wrote:
Are expressions like ((uid_t)0-1) portable/safe ? Maybe that's a better
way of approaching this.
To get the all-1's number, maybe it's better to use ((uid_t)~0), but
that is a rather controversial
Garrett Wollman wrote:
On Mon, 13 Mar 2000 00:06:19 +, Paul Richards [EMAIL PROTECTED] said:
We could create a new include file that we use for constants that are
related to FreeBSD specific types or we can agree on a coding style for
performing bounds checking using tricks like
John Polstra wrote:
In article [EMAIL PROTECTED],
Paul Richards [EMAIL PROTECTED] wrote:
They must not go into limits.h. That header file is defined by
the ANSI/ISO C standard. The standard doesn't permit polluting the
namespace with extra stuff.
Umm, ok. I don't think our
Peter Jeremy wrote:
On 2000-Mar-13 12:01:03 +1100, Paul Richards [EMAIL PROTECTED] wrote:
id = strtoul(p, (char **)NULL, 10);
if ((errno == ERANGE) || (id = UID_MAX)) {
warnx("%s max uid value (%lu)", p, UID_MAX);
return (0);
}
You can do this now.
John Polstra wrote:
In article [EMAIL PROTECTED],
Paul Richards [EMAIL PROTECTED] wrote:
John Polstra wrote:
I guess it could go into machine/limits.h in the
"!defined(_ANSI_SOURCE)" section. Bruce might have a better idea.
I don't think machine/limits.h is the r
Peter Jeremy wrote:
On 2000-Mar-13 13:14:40 +1100, Paul Richards [EMAIL PROTECTED] wrote:
#define UID_MAX ((uid_t)0-1)
...
I can see the flaw in that straight away in that uid_t isn't available
in sys/syslimits.h
Not a problem. C macros are just text expansions. The `uid_t' isn't
The fix I applied to pwd_mkdb is an improvement over what was there
before i.e. nothing, but is a poor solution at the moment since it won't
work correctly on the alpha.
The following code snippet is OK on the i386 but on the alpha ULONG_MAX
is 64 bits and so is a totally wrong constant to check
John Polstra wrote:
In article [EMAIL PROTECTED],
Paul Richards [EMAIL PROTECTED] wrote:
I think we need a MAX_UID and a MAX_GID to perform checks like this.
Anyone got any objections to adding them to /usr/include/limits.h ?
They must not go into limits.h. That header file
Kris Kennaway wrote:
On Fri, 10 Mar 2000, Paul Richards wrote:
Non-root users can use the pw command to get information from the
master.passwd file e.g.
ps showuser paul
paul:*:1000:1000::0:0: Richards:/home/paul:/usr/local/bin/bash
% pw showuser kkenn
kkenn:*:1000:0::0:0
Non-root users can use the pw command to get information from the
master.passwd file e.g.
ps showuser paul
paul:*:1000:1000::0:0: Richards:/home/paul:/usr/local/bin/bash
which shows the class, password expiry and account expiry. I'm not sure
whether that's information that should be kept secure
Mark Murray wrote:
Mark Murray wrote:
I'm very uncomfortable with requiring Yet Another Daemon to manage
(and screw up) password checking. Generally speaking, if I wouldn't
trust a program with root privileges, I wouldn't trust it with my
password, either (for obvious
Jonathan Lemon wrote:
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write:
Kai Großjohann wrote:
"Jordan K. Hubbard" [EMAIL PROTECTED] writes:
I really kinda wish you'd point them to Novice^H^H^H^H^HStandard
instead since it does more than be a bit more verbose, it
87 matches
Mail list logo