On Mon, Sep 24, 2007 at 04:44:09PM +0100, Chris wrote:
> On 24/09/2007, Jeremy Chadwick <[EMAIL PROTECTED]> wrote:
> > On Mon, Sep 24, 2007 at 12:57:23AM +0100, Chris wrote:
> > > nfe0: flags=8843 mtu 1500
> > > options=8
> > > inet x.x.x.x netmask 0xff00 broadcast x.x.x.x
On Mon, Sep 24, 2007 at 05:17:40PM +0100, Chris wrote:
> On 24/09/2007, Jeremy Chadwick <[EMAIL PROTECTED]> wrote:
> > On Mon, Sep 24, 2007 at 12:57:23AM +0100, Chris wrote:
> > > nfe0: flags=8843 mtu 1500
> > > options=8
> > > inet x.x.x.x netmask 0xff00 broadcast x.x.x.x
On 26/09/2007, Michael Butler <[EMAIL PROTECTED]> wrote:
> Chris wrote:
> > Hi I am concerned about the availabilities of these encryptions in
> > freebsd releases that are marked stable.
> >
> > It seems gbde has a problem when the the data written goes over the
> > lba boundary around lba48.
>
>
> On Tue, 25 Sep 2007, LI Xin wrote:
> > Oliver Fromme wrote:
> > > Nicolas Rachinsky wrote:
> > > > Oliver Fromme wrote:
> > > > > By the way, an additional confusion is that ".." and "../"
> > > > > are handled differently. Specifying ".." always leads to
> > > > > this message:
> >
Chris wrote:
> Hi I am concerned about the availabilities of these encryptions in
> freebsd releases that are marked stable.
>
> It seems gbde has a problem when the the data written goes over the
> lba boundary around lba48.
Could you please test the attached patch to /usr/src/sys/dev/ata/ata-al
Hi I am concerned about the availabilities of these encryptions in
freebsd releases that are marked stable.
It seems gbde has a problem when the the data written goes over the
lba boundary around lba48.
http://lists.freebsd.org/pipermail/freebsd-geom/2007-August/002524.html
I suffered this probl
On Tue, 25 Sep 2007, LI Xin wrote:
I think this is a bug, here is a fix obtained from NetBSD.
This bug, if any, cannot be fixed in rm.
The reasoning (from NetBSD's rm.c,v 1.16):
Bugs can easily be added to rm.
Strip trailing slashes of operands in checkdot().
POSIX.2 requires that if ".
On 9/26/07, Dan Nelson <[EMAIL PROTECTED]> wrote:
> In the last episode (Sep 26), Oliver Fromme said:
> > Bob Johnson wrote:
> > > Maybe. But I expect that the behavior for "rm -rf .." is there so
> > > that things don't get REALLY astonishing when you do "rm -rf *".
> >
> > The expansion of "*"
Alex Zbyslaw wrote:
> .??* is a standard workaround that works most of the time. Won't match
> .a .b etc but such antisocial files are the exception, one might hope.
What? I name all my files that way!
Granted, that only allows under 30 files per directory, but so what?
--
Tuomo
... Alright!
Dan Nelson wrote:
> Oliver Fromme said:
> > The expansion of "*" does not include "." or "..".
>
> Under /bin/sh, ".*" does match "." and "..", so be careful :)
For that reason I got used to type ".??*" instead of ".*"
since I started with UNIX almost 20 years ago. ;-)
Apart from that, zsh
Dan Nelson wrote:
In the last episode (Sep 26), Oliver Fromme said:
Bob Johnson wrote:
> Maybe. But I expect that the behavior for "rm -rf .." is there so
> that things don't get REALLY astonishing when you do "rm -rf *".
The expansion of "*" does not include "." or "..".
Under /bin
In the last episode (Sep 26), Oliver Fromme said:
> Bob Johnson wrote:
> > Oliver Fromme wrote:
> > > By the way, an additional confusion is that ".." and "../"
> > > are handled differently. Specifying ".." always leads to
> > > this message:
> > >
> > > rm: "." and ".." may not be removed
On Tue, 25 Sep 2007, LI Xin wrote:
> Oliver Fromme wrote:
> > Nicolas Rachinsky wrote:
> > > Oliver Fromme wrote:
> > > > By the way, an additional confusion is that ".." and "../"
> > > > are handled differently. Specifying ".." always leads to
> > > > this message:
> > > >
> > > >
Artem Kuchin wrote:
> Well, problem with top is that on dual 3GHZ box it alsway s
> shows 0% load when not loaded with real traffic (web traffic) no matter
> if it is polling of int handling.
Great, so your machine doesn't have any significant overhead
for the timer interrupt. That was your qu
Bob Johnson wrote:
> Oliver Fromme wrote:
> > By the way, an additional confusion is that ".." and "../"
> > are handled differently. Specifying ".." always leads to
> > this message:
> >
> > rm: "." and ".." may not be removed
> >
> > and nothing is actually removed. It is confusing th
> My guess is that you forgot to include "options SMP" in
> your kernel config. Otherwise, what's the output from
> "sysctl kern.smp" on that machine?
>
> Best regards
>Oliver
>
Sorry, my bad, everything works like a charm.
I forgot that SMP config is just include GENERIC + options SMP
and
16 matches
Mail list logo
