In article <[EMAIL PROTECTED]> Nate writes:
>I note that David is no longer on the list ([EMAIL PROTECTED] was
>'unsubscribed, either accidentally or intentionally). Justin is gone,
>and many other folks I would have considered to be folks interested that
>were once subscribed...
"Accidental" re
In article <[EMAIL PROTECTED]> you
write:
> only one comment. i remove people from the lists whenever
>their email bounces. the threshhold is approximately 30 messages in a
>24 hour period. mail may bounce due to DNS problems, mail box full,
>MTA misconfiguration. i also remove people
In article <[EMAIL PROTECTED]> you write:
>You have no way of knowing whether inbound mail to you has bounced, or
>not. Why are you so adamant that mail has not bounced?
Becuse I get lots of email, because I check it constantly, because any of a
half dozen sources for it bouncing would result in
>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 Mille
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
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:
>
>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.
>
>I'll tell you in case you can't figure out the answer to that rather
>simple question: You're annoying
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
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
>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 sem
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 pos
In article
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 client *does* have a very extensive configuration file. Same
parse
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
In article
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 happens
>if your lease expires and doesn't get renewed, or gets ren
>> 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
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 that
>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 wa
>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.
___
freebsd-current@fre
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
https:
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 mailing
21 matches
Mail list logo
