Run! Its a mutant three-eared Glenda! ;-)
Thanks,
Roman.
On Tue, 2008-12-30 at 10:31 -0500, erik quanstrom wrote:
> > You have to ensure that I can't dial it and authenticate with
> > factotum. It's a mess!)
>
> how would that attack work?
>
> supposing that you have a fully jailed process. if it has a connection
> to the fileserver, which does do se
there are a couple of cases where the database= lines in ndb
files don't appear to me to work as one would expect.
ndbsearch(2) searches the original file and all the files in
the database= lines. however ndbparse(2) opens only the
named file; ndbreopen(2) only reopens the named file.
so, e.g.,
this is otherwise known as how to shove a round peg in a
square hole. but the inefficency doesn't much matter.
i have an ancient unix program called tel. i wrote it in
1988 so it has no relation to tel(1). tel is a simple
address book. recently it's been abused to store account
information tha
On Thu, Jan 01, 2009 at 02:53:33PM -0800, Roman V. Shaposhnik wrote:
> On Tue, 2008-12-30 at 10:31 -0500, erik quanstrom wrote:
> > > You have to ensure that I can't dial it and authenticate with
> > > factotum. It's a mess!)
> >
> > how would that attack work?
> >
> > supposing that you have a f
Suject: scuzz(8) man bug
man -P, man or the magicman html versions
all have a similar bug. the .IR macro appends a
a spurious ".}f".
SEE ALSO
sd(3)
Small Computer System Interface - 2 (X3T9.2/86-109), .}f
shortening the italic portion by 4 characters makes the problem
g
The EXAMPLES section of `man 1 grap' contains an "extra paste" error: `.G1'
marks the start of a graph description and `.G2' the end -- everything in the
middle has been re-pasted after the `.G2'.
In short:
remove lines grap(1):138 through grap(1):150
ak
> ndbsearch(2) searches the original file and all the files in
> the database= lines. however ndbparse(2) opens only the
> named file; ndbreopen(2) only reopens the named file.
It may be that you want to limit the search to a single database
element and then there is no way to do it. The databas
> lucio also found that i had absolutely no idea what i was
> doing with hbas that support Hsss (staggered spinup), at least for
> ich9m-based thinkpads.
Flattering as this is, I do not recall such a thing. I made only an
insignificant contribution regarding flash, if my memory isn't too
muddled.
On Thu Jan 1 22:47:59 EST 2009, lu...@proxima.alt.za wrote:
> > lucio also found that i had absolutely no idea what i was
> > doing with hbas that support Hsss (staggered spinup), at least for
> > ich9m-based thinkpads.
>
> Flattering as this is, I do not recall such a thing. I made only an
> in
I think you got the names mixed up, I had problems with the sata and
the 82567 on my thinkpad. :)
Thanks,
Lucho
On Thu, Jan 1, 2009 at 9:16 PM, erik quanstrom wrote:
> On Thu Jan 1 22:47:59 EST 2009, lu...@proxima.alt.za wrote:
>> > lucio also found that i had absolutely no idea what i was
>
> I think you got the names mixed up, I had problems with the sata and
> the 82567 on my thinkpad. :)
but unless i've really gone mad, the staggered spinup
was the sata and the flash/nvram was the 82567.
- erik
> I think you got the names mixed up, I had problems with the sata and
> the 82567 on my thinkpad. :)
Yes, even I get us mixed up.
I'm glad you don't seem to, although I am rather jealous that in your
much shorter relationship with Plan 9, you have achieved infinitely
more.
:-)
++L
13 matches
Mail list logo