On 07/08/2012 23:16, Avleen Vig wrote:
On Sun, Jul 8, 2012 at 10:51 PM, Doug Barton do...@freebsd.org wrote:
On 07/08/2012 22:43, Avleen Vig wrote:
It would be silly not to keep bind-tools in base.
Sounds easy, but not so much in practice. Keeping any of the code
doesn't solve the problem of
On 07/09/2012 00:34, Avleen Vig wrote:
On Sun, Jul 8, 2012 at 11:26 PM, Doug Barton do...@freebsd.org wrote:
On 07/08/2012 23:16, Avleen Vig wrote:
On Sun, Jul 8, 2012 at 10:51 PM, Doug Barton do...@freebsd.org wrote:
On 07/08/2012 22:43, Avleen Vig wrote:
It would be silly not to keep
On 7/9/12 12:44 AM, Dan Lukes wrote:
On 07/08/12 23:55, Doug Barton:
On 07/08/2012 07:41, Dan Lukes wrote:
...
Sorry, you're not understanding what is being proposed. Specifically
you're confusing the system stub resolver (the bit that's compiled into
libc, and used by binaries) and the
Avleen Vig avl...@gmail.com writes:
It would be silly not to keep bind-tools in base. `host` and `dig` are
very standard tools most people expect to be available in base, just
as they are in the base/core/whatever of other operating systems.
We should definitely have an implementation of
Avleen Vig avl...@gmail.com writes:
As bind-tools and BIND (the resolver) as separate, why not just leave
bind-tools in base? They'll work happily with unbound.
The bind-tools (host, dig, nslookup) are command-line frontends for the
resolver.
Perhaps what you are trying to say is that they are
Gabor Kovesdan ga...@freebsd.org writes:
Other than the functionality, when we replace something, it is also
important to do some benchmarks and assure that the performance is not
reasonably worse. Some time back I committed the error of not
carefully pass this requirement with BSD grep but so
On Sun, Jul 8, 2012 at 10:29 AM, Doug Barton do...@freebsd.org wrote:
Unbound has different policies and release schedules that are more in
line with ours. So in the short term (as in, the next few years) we're
better off with unbound in the base.
Where is there information about this / what
On Sat, Jul 7, 2012 at 4:38 PM, Doug Barton do...@freebsd.org wrote:
On 07/07/2012 16:33, Garrett Wollman wrote:
On Sat, 07 Jul 2012 16:17:53 -0700, Doug Barton do...@freebsd.org said:
BIND in the base today comes with a full-featured local resolver
configuration, which I'm confident
On Sun, Jul 8, 2012 at 2:39 PM, Doug Barton do...@freebsd.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/08/2012 10:10, Jason Hellenthal wrote:
From first impression it seems that drill(1) has a syntax that
leaves something to be desired like the eased use of host or dig.
On Sun, Jul 8, 2012 at 10:51 PM, Doug Barton do...@freebsd.org wrote:
On 07/08/2012 22:43, Avleen Vig wrote:
It would be silly not to keep bind-tools in base.
Sounds easy, but not so much in practice. Keeping any of the code
doesn't solve the problem of the release cycles not syncing up. And
On Sun, 8 Jul 2012 23:16:04 -0700, Avleen Vig avl...@gmail.com said:
I could care less about the resolver daemon itself, I agree with what
you're saying and I don't think most end users will care about that.
But getting rid of dig and host in base would be bad.
I don't think it's as bad as
On Sun, Jul 8, 2012 at 11:26 PM, Doug Barton do...@freebsd.org wrote:
On 07/08/2012 23:16, Avleen Vig wrote:
On Sun, Jul 8, 2012 at 10:51 PM, Doug Barton do...@freebsd.org wrote:
On 07/08/2012 22:43, Avleen Vig wrote:
It would be silly not to keep bind-tools in base.
Sounds easy, but not so
On Monday 09 July 2012 09:34:34 Avleen Vig wrote:
The issue is also one of barrier-to-entry. By removing `dig` and
`host`, I think we're making things unnecessarily more difficult for
people who don't *know* FreeBSD. `dig` and `host` a universally
standard tools for doing DNS lookups. Taking
On 9 Jul 2012, at 08:34, Avleen Vig wrote:
Agreed. The idea of a minimally functional system itself might be
flawed. Do you consider having `dig` and `host` essential in a
minimally functioning system? I do.
It's pretty f'king hard to resolve problems with installing the
bind-utils port,
On Friday, July 06, 2012 4:45:55 pm Arnaud Lacombe wrote:
Hi,
On Fri, Jul 6, 2012 at 3:09 PM, Ian Lepore
free...@damnhippie.dyndns.org wrote:
On Fri, 2012-07-06 at 14:46 -0400, Arnaud Lacombe wrote:
Hi,
On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe lacom...@gmail.com
wrote:
On Monday, July 09, 2012 12:39:03 am Warner Losh wrote:
On Jul 8, 2012, at 9:59 PM, Arnaud Lacombe wrote:
Hi,
On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh i...@bsdimp.com wrote:
On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote:
Ok, yet another Newbus' limitation. Assuming a
On Mon, Jul 9, 2012 at 12:34 AM, Avleen Vig avl...@gmail.com wrote:
[snip]
The issue is also one of barrier-to-entry. By removing `dig` and
`host`, I think we're making things unnecessarily more difficult for
people who don't *know* FreeBSD. `dig` and `host` a universally
standard tools for
On Mon, Jul 09, 2012 at 09:42:43AM -0700, Jos Backus wrote:
On Mon, Jul 9, 2012 at 12:34 AM, Avleen Vig avl...@gmail.com wrote:
[snip]
The issue is also one of barrier-to-entry. By removing `dig` and
`host`, I think we're making things unnecessarily more difficult for
people who
Thanks Kim.
That's very helpful.
One more question, to get teh RAM of the system, is the way r190599
reliable? Could we trust env variable to get memory reading from bios?
If I would like to calculate the RAM from
totalmem = physmem 12 + reserve_memory+ msgbuff_size
How can I get size
Ran into some symbol errors with the dtraceall module when using the
*old* nfs client.
I think that this is more or less the right thing to do, but I'm not
sure.
--- //depot/yahoo/ybsd_9/src/sys/modules/dtrace/dtraceall/dtraceall.c
2011-11-02 23:46:55.0
+++
On Sun, Jul 08, 2012 at 02:21:46 -0700 , Doug Barton wrote:
That's an implementation issue, and is easily handled with drill, or the
host-like program we all agree is a really-nice-to-have.
About that: as I said elsewhere in one of these threads (I want my
bikeshed clear and chartreuse at the
On 2012-Jul-09 14:15:13 +0200, in freebsd-security, Andrej (Andy) Brodnik
and...@brodnik.org wrote:
Excuse my ignorance - but is there a how-to paper on transition from
bind to unbound for SOHO?
In particular, if unbound has no authoritative server capabilities, what
suggestions are there for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/09/2012 13:47, Peter Jeremy wrote:
On 2012-Jul-09 14:15:13 +0200, in freebsd-security, Andrej (Andy)
Brodnik and...@brodnik.org wrote:
Excuse my ignorance - but is there a how-to paper on transition
from bind to unbound for SOHO?
You
On 07/09/2012 06:33, Jonathan McKeown wrote:
On Monday 09 July 2012 09:34:34 Avleen Vig wrote:
The issue is also one of barrier-to-entry. By removing `dig` and
`host`, I think we're making things unnecessarily more difficult for
people who don't *know* FreeBSD. `dig` and `host` a universally
On 07/09/2012 06:45, Mark Blackman wrote:
Indeed, 'dig' and 'host' must be present and working as expected
in a minimally installed system.
So if you don't like the versions that get imported, install bind-tools
from ports.
Doug
--
This .signature sanitized for your protection
on 09/07/2012 22:49 Sean Bruno said the following:
Ran into some symbol errors with the dtraceall module when using the
*old* nfs client.
I think that this is more or less the right thing to do, but I'm not
sure.
--- //depot/yahoo/ybsd_9/src/sys/modules/dtrace/dtraceall/dtraceall.c
On 9 Jul 2012, at 22:01, Doug Barton wrote:
On 07/09/2012 06:45, Mark Blackman wrote:
Indeed, 'dig' and 'host' must be present and working as expected
in a minimally installed system.
So if you don't like the versions that get imported, install bind-tools
from ports.
my DNS resolution
Mark Blackman m...@exonetric.com writes:
my DNS resolution is broken, so my ports can't download any tarballs.
In this case, I reach for dig to see which part of the DNS resolution
chain is failing me.
At the bare minimum, 'dig' should be an alias for 'drill', which I have
to say isn't
On 9 Jul 2012, at 22:37, Dag-Erling Smørgrav wrote:
Mark Blackman m...@exonetric.com writes:
my DNS resolution is broken, so my ports can't download any tarballs.
In this case, I reach for dig to see which part of the DNS resolution
chain is failing me.
At the bare minimum, 'dig' should
Mark Blackman m...@exonetric.com writes:
I never use '-t' with dig. drill *told* me I should use '-t' then
completely failed to acknowledge I had done so.
Marks-Macbook% drill -t www.google.com
[...]
;; WARNING: The answer packet was truncated; you might want to
;; query again with TCP (-t
On 9 Jul 2012, at 23:01, Dag-Erling Smørgrav wrote:
Mark Blackman m...@exonetric.com writes:
I never use '-t' with dig. drill *told* me I should use '-t' then
completely failed to acknowledge I had done so.
Marks-Macbook% drill -t www.google.com
[...]
;; WARNING: The answer packet was
Mark Blackman m...@exonetric.com writes:
drill certainly looks like a drop-in replacement for the common case
as you suggest. But if it's not called 'dig' and I've never heard of
'drill', I'm unlikely to reach for 'drill', hence the alias
suggestion. I *had* never heard of 'drill' until this
On 07/09/12 17:01, Doug Barton wrote:
On 07/09/2012 06:45, Mark Blackman wrote:
Indeed, 'dig' and 'host' must be present and working as expected
in a minimally installed system.
So if you don't like the versions that get imported, install bind-tools
from ports.
Doug
Doug, you are one of
Firstly, I should note that I'm not against removing bind from base.
I'm merely saying that users are going to need some guidance during
the transition.
On 2012-Jul-09 13:52:15 -0700, Doug Barton do...@freebsd.org wrote:
On 07/09/2012 13:47, Peter Jeremy wrote:
On 2012-Jul-09 14:15:13 +0200, in
On 2012-Jul-10 00:40:07 +0200, Dag-Erling Smørgrav d...@des.no wrote:
They are sufficiently similar that writing a wrapper that supports a
significant subset of dig's command-line option and uses drill as a
backend shouldn't take more than an afternoon for a reasonably
experienced programmer.
I
On Jul 9, 2012 7:57 PM, Peter Jeremy pe...@rulingia.com wrote:
On 2012-Jul-10 00:40:07 +0200, Dag-Erling Smørgrav d...@des.no wrote:
They are sufficiently similar that writing a wrapper that supports a
significant subset of dig's command-line option and uses drill as a
backend shouldn't take
36 matches
Mail list logo
