On Fri, 9 Jun 2000, Kris Kennaway wrote:
dotfiles for example). I don't believe there's such a thing as a lowest
common denominator of file system naming conventions - either a filesystem
can support UFS names (perhaps through a translation later) or it's not
suitable for running FreeBSD
Okay, answering my own question for the sake of the archive, I believe it
was an on combination of some of the options SC_something that
vidcontrol -m on and my mouse and kernel didnt like. I was using some to
save on kernel size and memory used but then decided to start using the
computer
Okay, answering my own question for the sake of the archive, I believe it
was an on combination of some of the options SC_something that
vidcontrol -m on and my mouse and kernel didnt like. I was using some to
save on kernel size and memory used but then decided to start using the
computer
On Fri, Jun 09, 2000 at 11:23:58PM -0700, Andrey A. Chernov wrote:
On Fri, Jun 09, 2000 at 07:37:09PM -0400, Jeroen C. van Gelderen wrote:
Why to XOR true random bits from arc4random() with non-random bits from
getpid()? It only weakens. Better way is just remove any getpid() code and
I dont recall exactly :( SC_NO_FONT_LOADING was one of them, I may have
commented one of the others in the old conf trying to fix it. I have a
spare comp with a freebsd install I could play around with it on and see
if I can recreate it instead of goofing around with my server that had the
On Fri, Jun 09, 2000 at 11:23:58PM -0700, Andrey A. Chernov wrote:
would be the way to go: 64^6 = 2^36 possibilities which is nice...
1) Just totally opposite: mixing random with non-random sources you'll get
into collision much faster then with random source only. 2) Yet, of course,
:1) Just totally opposite: mixing random with non-random sources you'll get
:into collision much faster then with random source only. 2) Yet, of course,
:the code handles collisions.
:
:--
:Andrey A. Chernov
:[EMAIL PROTECTED]
Think about it. If you mix a random number with a non-random
Why not just XOR the whole lot into the current ${randomnumber}?
That way, at least the effort of the whole calculation is not wasted
as much.
Why to XOR true random bits from arc4random() with non-random bits from
getpid()? It only weakens. Better way is just remove any getpid() code
Then you will get collisions which you will have to deal with. I am not
familiar with the code but if we can handle collisions nicely then that
would be the way to go: 64^6 = 2^36 possibilities which is nice...
1) Just totally opposite: mixing random with non-random sources you'll get
On Fri, Jun 09, 2000 at 08:28:06PM -0400, Brian Fundakowski Feldman wrote:
It's an issue. Nice values count for less than before due to fixes
that Luoqi Chen made (and I committed). The behavior now isn't optimal,
but it is better than the system locking up. NICE_WEIGHT might be okay
to
It's probably better to just get rid of the PID and use randomness
throughout the name than to use 72 characters. 64^6 vs. 2*(72^3) .
I seem to be in the minority on this, but in general I *like* the
idea that the tempfiles include the pid. It's bad because it makes
it easier for an evil-person
We have inb and outb. Can't vmware be written in Forth? If inl cannot be
replaced with inb, I'd rather add inl than vmware.
But we can't set registers to specific values before inb/outb, which also
means our inb/outb are quite useless in making BIOS calls.
IMHO, it would be better to add
On Sat, 10 Jun 2000, Volodymyr Kostyrko wrote:
On Fri, Jun 09, 2000 at 08:28:06PM -0400, Brian Fundakowski Feldman wrote:
It's an issue. Nice values count for less than before due to fixes
that Luoqi Chen made (and I committed). The behavior now isn't optimal,
but it is better than the
On Sat, Jun 10, 2000 at 10:56:00AM +0300, Volodymyr Kostyrko wrote:
I think this is not the clear solution for descibed problem 'couse the
dnetc client still gets a priority and still have the share of time while
other programs might run. For me idprio works great. Just change last
string
Kris Kennaway wrote:
Bad example. Not _all_ filenames but temp. ones only which allows to run
FreeBSD binary in MSDOS FS with MSDOS files.
The point is the same. Files created by FreeBSD binaries during the course
of operation don't conform to an 8.3 monocase naming scheme (think of
Kris Kennaway wrote:
Instead of using only alphabetic characters, the patch uses the following
character set:
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~
which is not believed to cause any problems with shells. The PID is also
Huh? # does not cause
As was pointed out, rcp.statd is supposed to have a large VSZ, but
mount_nfs should not and my swap was getting used up.
mount_nfs will do an RPC clntudp_create for every attempt, but
only a clnt_destroy after a success.
Here is a rather suspicious fix, I have not looked at rpc call
use in
This has been applied.
+ Kim
| From:"Andrey A. Chernov" [EMAIL PROTECTED]
| Date:Fri, 21 Apr 2000 08:36:12 +0400
|
| --- tc.prompt.c.bak Thu Apr 20 11:47:23 2000
| +++ tc.prompt.c Fri Apr 21 08:31:17 2000
| @@ -222,7 +222,7 @@
| fmthist('R', info, (char *) (cz
On Fri, 9 Jun 2000, John Hengstler wrote:
Greetings,
What is the quick way to restore the boot manager (dual os). Lost it when I
reloaded Win98.
man boot0cfg
Doug White| FreeBSD: The Power to Serve
[EMAIL PROTECTED] | www.FreeBSD.org
To Unsubscribe: send mail
On Sat, 10 Jun 2000, Kris Kennaway wrote:
Given the other replies in this thread I think I'll just remove the PID
stuff altogether and make the temp filename only constructed from
alphanumeric character. The price is that there's a chance of collision
between two programs who mktemp() and
Kris Kennaway wrote:
On Sat, 10 Jun 2000, Kris Kennaway wrote:
Given the other replies in this thread I think I'll just remove the PID
stuff altogether and make the temp filename only constructed from
alphanumeric character. The price is that there's a chance of collision
between two
Kris Kennaway wrote:
On Sat, 10 Jun 2000, Jeroen C. van Gelderen wrote:
Actually, it's not of course a security risk in the new algorithm (this is
mktemp() after all), but it's a potential failure mode which can cause
applications to fail in ways they otherwise wouldn't (with some
Recent compiler changes seem to have broken the ability to do 4.x
buildworlds under -current - I've tested this on beast.freebsd.org and my
own machines and got the same result. The build dies during the compiler
phase with lots of stuff like:
As for setting registers ti specific values... huh? Why does this
matter? Can you explain exactly what your code does and how?
VMware intercepts the inb/outb instruction to port 0x5658 when the eax
register is set to a magic value, otherwise it would be handled as any
other ports.
-lq
To
As for setting registers ti specific values... huh? Why does this
matter? Can you explain exactly what your code does and how?
VMware intercepts the inb/outb instruction to port 0x5658 when the eax
register is set to a magic value, otherwise it would be handled as any
other ports.
I
I just came over from 4.0 yesterday, and now I get some odd messages
that weren't there before.
unknown0: PNP0c01 at iomem
0-0x9fbff,0x9fc00-0x9,0xe-0xf,0x10-0x4fe,0x4ff-0x4ff7fff,0x4ff8000-0x4ff,0xfffc-0x
on isa0
unknown: PNP can't assign resources
On Sat, Jun 10, 2000 at 02:31:23PM -0700, Kris Kennaway wrote:
between two programs who mktemp() and come up with the same random
filename, which is a theoretical security risk (at present only something
with the same PID can come up with a colliding tempfile name) but the
probability is
On Fri, Jun 09, 2000 at 11:53:34PM -0700, Matthew Dillon wrote:
:1) Just totally opposite: mixing random with non-random sources you'll get
:into collision much faster then with random source only. 2) Yet, of course,
:the code handles collisions.
:
:--
:Andrey A. Chernov
:[EMAIL
On Sat, Jun 10, 2000 at 09:13:30AM +0200, Mark Murray wrote:
Well, I tend to agree that it is not weakens random, but I not see any
improvement too.
That is a pretty fundamental theorem of Cryptography. My suggestion
_strengthens_ the random number. All you lose is one bit if it
If it not
On Sat, Jun 10, 2000 at 07:43:06PM -0700, Andrey A. Chernov wrote:
On Sat, Jun 10, 2000 at 09:31:49AM +0200, Mark Murray wrote:
Incorrect. See my other mail; ${RANDOM} xor ${PREDICTABLE} is random.
Only if predictable have the same bits number as random. If not all bits of
random XOR-ed
On Sat, Jun 10, 2000 at 07:36:10PM -0700, Andrey A. Chernov wrote:
On Fri, Jun 09, 2000 at 11:53:34PM -0700, Matthew Dillon wrote:
:1) Just totally opposite: mixing random with non-random sources you'll get
:into collision much faster then with random source only. 2) Yet, of course,
On Sat, Jun 10, 2000 at 09:24:28PM -0400, Ray Kohler wrote:
I just came over from 4.0 yesterday, and now I get some odd messages
that weren't there before.
unknown0: PNP0c01 at iomem
On Sat, Jun 10, 2000 at 11:19:01PM -0400, Brian Reichert wrote:
On Sat, Jun 10, 2000 at 09:24:28PM -0400, Ray Kohler wrote:
I just came over from 4.0 yesterday, and now I get some odd messages
that weren't there before.
unknown0: PNP0c01 at iomem
On Sun, Jun 11, 2000 at 12:30:45AM -0400, Ray Kohler wrote:
On Sat, Jun 10, 2000 at 11:19:01PM -0400, Brian Reichert wrote:
I would hazard the guess that you now have the PNPBIOS directive
in your kernel config file...
Actually, I don't have PnP in my config file. That's why I think
this
On Sat, Jun 10, 2000 at 09:33:51PM -0700, Chris Piazza wrote:
On Sun, Jun 11, 2000 at 12:30:45AM -0400, Ray Kohler wrote:
On Sat, Jun 10, 2000 at 11:19:01PM -0400, Brian Reichert wrote:
I would hazard the guess that you now have the PNPBIOS directive
in your kernel config file...
:Here is a rather suspicious fix, I have not looked at rpc call
:use in detail:
:
:--- mount_nfs.c.origSat Jun 10 11:08:19 2000
:+++ mount_nfs.c Sat Jun 10 11:09:06 2000
:@@ -784,10 +784,11 @@
:warnx("%s", clnt_sperror(clp,
:
36 matches
Mail list logo
