Hello!
I'm curious... Why is localhost delivery encrypted by default in the first
place?
I have this in /etc/mail/access:
#
# Disable local encrypted connections:
Srv_Features:localhost S
#
John Marshall john.marsh...@riverwillow.com.au wrote:
I also note that phk@ was working on an ntp client which he hoped to
offer as a replacement but that is presumably not ready yet. I also
note that we have current versions of ntp available in ports; but I'm
talking about what we ship in
Scott Bennett wrote:
> thousand blocks allocated. Directories don't shrink. Directory entries do
> not get moved around within directories when files are added or deleted.
> Directories can remain the same length or they can grow in length. If a
> directory once had many tens
Freddie Cash wrote:
> Huh, never even noticed (not that I use many of the grep variants). But,
> on a 10.3 install (from binaries, not source), half the variants are
> hard-links to bsdgrep, while the other half are hard-links to grep:
Yep, that's how it was for me.
>
I've just noticed that the hard links for xzgrep / xzegrep / xzfgrep / lzgrep /
lzgrep / lzfgrep
are missing from my source-built FreeBSD 11 release.
I've tracked it down to a commit almost 2 years ago..
https://svnweb.freebsd.org/base/head/usr.bin/grep/Makefile?r1=277939=284345=315687
Am I
Kyle Evans wrote:
> >
> > Am I really the first to notice, or am I missing something here?
>
> Yes, but only slightly. =) If you do `grep -V`, you should find that
> your system is actually using GNU grep. Please refer to:
>
Kyle Evans wrote:
> Ah, I see what you mean. I've no idea on the history here, but I
> believe the idea is that if I invoke one of these other links (zgrep,
> egrep, ...) I'm expecting it to be actually be grep(1) based purely on
> the name, and I don't consider bsdgrep(1) to
> Anyway, in this case, there should be options for the moderators to block
> certain servers, addresses and users.
Whilst I agree, the thing that makes my use of these lists less effective is
the indiscriminate top posting and even worse, the total lack of reply-trimming.
Cheers, Jamie
Remember, it's not simply deprecating cards less than 1Gig.
I have a card that is 10/100 only, but works fine with the gigabit alc driver:
alc0: port 0x2000-0x207f mem
0xe050-0xe053 irq 16 at device 0.0 on pci1
cheers, jamie
___
Brooks Davis wrote:
> On Fri, Oct 05, 2018 at 04:18:22PM +0100, Jamie Landeg-Jones wrote:
> > Remember, it's not simply deprecating cards less than 1Gig.
> >
> > I have a card that is 10/100 only, but works fine with the gigabit alc
> > driver:
> >
/usr/src/UPDATING contains the line:
"WITHOUT_DRM_MODULE=t and WITHOUT_DRM2_MODULE=t to avoid nasty"
This should be:
WITHOUT_MODULE_DRM and WITHOUT_MODULE_DRM2=t to /etc/src.conf to avoid nasty"
(I also added the reference to /etc/src.conf which I think is missing)
cheers, Jamie
I've noticed a replicable disk corruption by fsck_ufs/ffs on sparse files.
This is on amd/64 12-stable-20190409, but I first noticed it on
12-stable-20190326.
I didn't notice it on my previous build of 12-stable-20190107, but I
may not have had any relevant sparse files at the time, so I don't
Kirk McKusick wrote:
> > From: Peter Holm
> >
> > On Fri, Apr 12, 2019 at 04:13:00PM -0700, Kirk McKusick wrote:
> >
> >> This is indeed a bug in the calculation of the location of the last
> >> block of a file. I believe that the following patch to head will
> >> fix it.
> >>
> >> Peter,
Daniel Braniss wrote:
> Hi,
> I just compiled r355429 for amd64, and noticed that the compilation date is
> missing from ‘name -a’.
> FreeBSD hp-600 12.1-STABLE FreeBSD 12.1-STABLE r353429 HUJI amd64
>
> there is a now (maybe for a long time?) a -R option to newvers.sh.
> is there an option
Andy Farkas wrote:
> Just still wondering what 'assfail' could be.
Don't google it!!
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to
15 matches
Mail list logo