Given the recent posting of DVD movie decryption code (see Slashdot
for details), I was wondering if there was interest for code that
does CSS authentication for DVD-ROM drives.
I looked at the slashdot posts, and was surprised (I guess) to see that nobody
seems to know about the Digital
In article [EMAIL PROTECTED] you write:
The p_args.patch patch implements a cache of the commandline arguments
in the process structure and makes ps(1) pick it up from there with
sysctl rather than by groping around in the target process memory.
I don't think this should go in at all.
It
In article [EMAIL PROTECTED] you
write:
I am all for removing -e, but I don't really like the idea of making
it optional nor do I like the idea of trying to maintain the capability
for the user's own processes - that simply makes the code even more
complex then it already is.
In article [EMAIL PROTECTED] PHK writes:
NOTE TO="SELF"
Maybe we should put a special marker in -currents sendmail and
reject all email to the current list if they don't originate
from such a system.
/NOTE
I'll tell you in case you can't figure out the answer to that rather
simple question:
In article 29763.917434096.kithrup.freebsd.curr...@critter.freebsd.dk you
write:
The biggest impact of this is a new argument to the suser() call
all over the kernel:
suser(NOJAIL, bla, bla);
or
suser(0, bla, bla);
Oh, goody, more gratuitious incomaptibilities with everyone else.
In article 199901271944.laa15317.kithrup.freebsd.curr...@kithrup.com you
write:
all over the kernel:
suser(NOJAIL, bla, bla);
or
suser(0, bla, bla);
Oh, goody, more gratuitious incomaptibilities with everyone else.
And to followup to my own message, since nobody else has:
This is
But then we're still having an API change that doesn't have to be there.
No, it's not.
If you change suser() to:
int
suser(uc, ac)
struct ucred *uc;
u_short *ac; {
return JAILsuser(0, uc, ac);
}
then suser() continues to have the same
In article 19990209074440.15845.qmail.kithrup.freebsd.curr...@rucus.ru.ac.za
you write:
Is DHCP core functionality?
As much as an editor and PPP are, yes -- without it, some people simply
*cannot* get on the net.
Anyone putting any DHCP functionality in should look
very seriously at any
In article xfmail.990209165224.doconnor.kithrup.freebsd.curr...@gsoft.com.au
you write:
Hmmm.. This annoyed me actually..
There is NO config file which means its damn annoying for you to tweak how it
works..
Would you please settle on a set of misinformation and stick with it?
isc-dhcp's
In article 19990209082922.17759.qmail.kithrup.freebsd.curr...@rucus.ru.ac.za
you write:
- DHCP-WIDE requires you to have bpf configured into your kernel
for a GENERIC kernel, this is VERY BAD - is there a more elegant
way to handle this? I certainly would not like to see the
generic
In article 19990209091330.18608.qmail.kithrup.freebsd.curr...@rucus.ru.ac.za
you write:
I would still
be very reticent to see BPF in a generic kernel because of the security
implications.
I'm sorry, but that's a complete non-issue:
1. /dev/bpf0 is mode 400, root.wheel -- to read it, you need
In article
e10a862-gy-00.qmail.kithrup.freebsd.curr...@myrddin.demon.co.uk you write:
What impact will this have on the rc files? How will it affect
rc.conf, seeing as it overrides several values therein?
PAO already has some support for this; it works, and is what I've been using.
What
Here's a thing I've missed a couple of times: I'd like to be
able to see the limits for a process in /proc.
At some point, I want to add an ioctl to get various process information
(well, multiple ioctl's, I think); SysVr4 has a bunch, and that's what I'd
model it on.
I'd like to be able to
>I think vm-bhyve hides stderr output from bhyve by default, but there might
>be a flag to make it display the stderr output. Can you try doing that to see
>if bhyve is reporting an error? Alternatively, can you see if the bhyve
>process is still running?
The log file from it is below. bhyve
Ok, with debug=yes I see that it *is* running the VM -- but I have no
serial console? This may be operator error here, which is a big relief.
An update after I get back from the vet :). Thanks!
Sean.
___
freebsd-current@freebsd.org mailing list
I get:
Loading kernel...
/boot/kernel/kernel text=0x16c493c data=0x1c8b38+0x819238
syms=[0x8+0x180c18+0x8+0x19df0b]
Loading configured modules...
can't find '/boot/entropy'
\
Note that I am using vm-bhyve as a management & control wrapper, so
>Could you test with larger memory setup - instead of 512M, 1-2G?
I tried multiple vcpus and 1G of RAM; it made no difference (to either my
attempting to boot the system I built, or the ISO; just confirmed the ISO with
1G).
Sean.
___
Ok, if I run the bhyve commands manually, then I get a serial console.
So something is just borked with vm-bhyve and its use of tmux. Whew.
(Now I don't know *what*, but that's at least progress in my diagnosis!)
___
freebsd-current@freebsd.org
18 matches
Mail list logo
