Hi,
I don't know whether the suggested approach is really a good one or not, but
as far as implementing some registry-like features in FreeBSD, we have
developped something that proves to be useful. The idea was to extend the
sysctl mechanism to make it dynamic from the user-land point of view. T
Hi,
> >Could these modifications be ported to -STABLE to ease up the transition
> >from -STABLE to -CURRENT ? I don't know if this is tied deeply on other
> >changes in -CURRENT, but if it is not I'd like to use the new facility.
>
> I think I would rather leave -stable out of this for now. Ther
"Poul-Henning Kamp" <[EMAIL PROTECTED]> wrote in message
news:<29877.980850630@critter>...
>
> I have made mount_mfs and vnconfig print a warning and sleep for 15
> seconds before continuing.
>
> Please convert to using mdconfig(8) for TMPFS uses.
>
> March 1st I will remove the functionality fr
Hi,
> > But from my list of wishes I'd say the first 3 are gone. All that's left
is
> > spanning tree. I'm probably going to need this pretty soon, so once more
> > I'm asking if anyone is working on it. If not I'll start on it.
>
> Do you have references for how to do this? As I understand it, t
Hi,
I have a patch against these warnings. They are the result of a function
being called with a pointer to a function rather than a string...
/otte/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/c-common.c:1655:
warning: passing arg 1 of `warning' from incompatible pointer type
/otte/src/
- Original Message -
From: "David O'Brien" <[EMAIL PROTECTED]>
> On Sun, Apr 09, 2000 at 02:44:25PM -0400, Patrick Bihan-Faou wrote:
> > I have integrated the source of qmail so it can be built as part of the
> > "world". I think that i
From: "Jon Parise" <[EMAIL PROTECTED]>
> On Sun, Apr 09, 2000 at 02:44:25PM -0400, Patrick Bihan-Faou wrote:
>
> > I have integrated the source of qmail so it can be built as part
> > of the "world". I think that it would be nice to have an
> >
Hi,
I have integrated the source of qmail so it can be built as part of the
"world". I think that it would be nice to have an alternative for the mailer
package to be built as part of a make world.
What I would like to do is upgrate the "NO_SENDMAIL" variable to a
"MAILER_SYSTEM" variable, which
Hi,
this is probably not news, but here is what I get.
I tried with both USA_RESIDENT=YES and no USA_RESIDENT defined...
The code has been CVSuped on tuesday Jan 18 2000 around 2am EST.
cc -O -pipe -DMONOLITH -DNO_IDEA -I/usr/src-freebsd-4.x/secure/usr.bin/opens
sl -DRSAref -I/usr/obj/usr/
Hi,
If we are changing the meaning of "USA_RESIDENT", could we replace it by
something else completely. I know that the USA are the center of the
universe ;-), but...
It seems to me that a things progress, the crypto regulation gets more
complicated everyday. Why not have a "CRYPTO_COUNTRY" vari
> No, this is completly reasonable now that I understand what it is your
> proposing. Even the memory footprint is minimal if pointers to the
> actual rules is all we store in the per interface list, my largest set
> duplicated over 8 interfaces would only be 3200 rules. Stored as
> pointers to
(don't you love all that quoting...)
> > > > I agree that having a `switch' type of rule for selecting interfaces
> > > > would be a reasonable gain of efficiency (but then again.. how
> > > > many interfaces is one using!)
> > >
> > > It doesn't matter, it has to do the lookup on a per-interface
Hi,
> > One of the things I would do to optimize ipfw is:
> > - instead of keeping one list with all the rules, split the list (the
> > internal one) by interface and by direction (one list for ed1
incoming,
> > one list for ed1 outgoing, etc.).
>
> I often do this manually in long rule sets
Hi Luigi,
> i am looking at (minor) optimizations of the ipfw code in order to reduce
> the running time in the common cases.
>
> I have a few ideas (mostly along the lines of optimizing for the
> most commonly-used rules). An obvious candidate is the 'match all'
> rule (all from any to any), bu
Hi,
Maybe I am wrong, but it seems to me that there is already quite a bit of
IPv6 and IPSec stuff in the tree. Most of the kernel stuff is there (albeit
seriously lacking documentation). To me this is not *too* critical right
now. I see the point for the research community though.
Also, regardi
Hi Julian,
> the kernel code for appletalk is 'out of date' but it is also
> somewhat modified..
>
> If you want to work with it, let me know and I can help as I did the
> original integration into our tree,
>
Well I would definitelly appreciate a quick summary of the changes that you
did to int
Hi,
I was looking at the netatalk package and the appletalk support in the
kernel source code and I realized that they are based on the same code
originally (the code from netatalk).
The kernel code however is quite out of date from what can be found in the
netatalk-asun package. I was wonderin
Hi,
Rather than going in horror shows like a registry editor look alike for the
kernel config, I think that there is a somewhat better approach to the
kernel configuration task. Has anybody taken a look at the configuration
script on RedHat-Linux distributions ? I don't know if it is RedHat spec
Hi,
From: Cy Schubert - ITSD Open Systems Group <[EMAIL PROTECTED]>
> > I was not talking about things that constitute the "real" core of the
> > distribution (kernel, basic libraries etc.). I was more thinking about
> > "userland" stuff that is included in the distribution but might not be
> > r
Hi,
From: Pierre Beyssac <[EMAIL PROTECTED]>
> There are a _lot_ of pitfalls to this kind of approach, as I have
> discovered using Linux Debian. This would probably open a can of
> worms you have no idea of. IMHO, the single biggest mistake in
> Debian is the all-encompassing package system whi
Hi All,
>It strikes me that having the base system be slightly more decomposed
> could be advantageous. It would be great to be able to do something like:
>
>pkg_delete lp
>pkg_delete yp
>
>Has anyone done/tried this in the past, and if so, what was the
> reaction? Or what do pe
21 matches
Mail list logo
