> At least i386, amd64, macppc, sparc64, hppa, and loongson
> are supported. Hopefully the others are not far behind.
Oh someone will ask how to verify this is working correctly. Well,
you can't really tell.
The following kernel diff will let you know that the propolice cookie
has come from dat
The i386 architecture has now been switched to PIE. There is a small
performance hit, but this part of ASLR is valuable combined with
W^X and the stack protector.
This is a non-trivial upgrade, so please be careful. Check the FAQ
for details or use a snapshot.
Over the holidays I've written code to do something we've
talked about for a long time but never gotten around to.
The bootblocks are now capable of providing entropy to the
kernel very early on.
This requires an upgrade of the bootblocks and at least
/etc/rc (which saves an entropy file for futu
On Sat, Dec 28, 2013 at 6:23 PM, Craig R. Skinner
wrote:
> On 2013-12-28 Sat 21:16 PM |, Craig R. Skinner wrote:
> > On 2013-12-19 Thu 13:43 PM |, Craig R. Skinner wrote:
> > > Enhance rc.d/rc.subr with lowered/raised daemon running priority.
> > >
> >
> > Take 2:
> >
> > Replace /etc/rc.d/ rc_ren
On 2013-12-28 Sat 15:13 PM |, Theo de Raadt wrote:
> > > Enhance rc.d/rc.subr with lowered/raised daemon running priority.
>
> You still have done nothing to prove the case for this extra
> complexity.
>
When I managed customer's dedicated servers, it would have been useful,
for example, to have
On 2013-12-28 Sat 21:16 PM |, Craig R. Skinner wrote:
> On 2013-12-19 Thu 13:43 PM |, Craig R. Skinner wrote:
> > Enhance rc.d/rc.subr with lowered/raised daemon running priority.
> >
>
> Take 2:
>
> Replace /etc/rc.d/ rc_renice=X with
> /etc/rc.conf.local _nice=X
>
Take 3 - simplify:
Use nic
> > This moves rgephy(4) back to using RL_GMEDIASTAT to read the link/media
> > status for re(4) attached Realtek PHY as was done before rev 1.25. rev
> > 1.25 was to add support for external rgephy(4) attached to other MAC
> > such as nfe(4), but the PHY Specific Status register doesn't seem to
>
> > Enhance rc.d/rc.subr with lowered/raised daemon running priority.
You still have done nothing to prove the case for this extra
complexity.
It's a custom thing you need, and noone else needs it.
2013/12/29 Mark Kettenis :
>> Date: Sat, 28 Dec 2013 22:37:52 +0100
>> From: Marc Espie
>> Reply-To: es...@nerim.net
>>
>> I'm thinking I'd like to impose a PATH for running @exec/@unexec
>> style lines in packing-lists.
>>
>> Some people have their default path ignoring /usr/local, which is just
> Date: Sat, 28 Dec 2013 22:37:52 +0100
> From: Marc Espie
> Reply-To: es...@nerim.net
>
> I'm thinking I'd like to impose a PATH for running @exec/@unexec
> style lines in packing-lists.
>
> Some people have their default path ignoring /usr/local, which is just
> fine, but the packages expect t
On Saturday, December 28, 2013, Marc Espie wrote:
> I'm thinking I'd like to impose a PATH for running @exec/@unexec
> style lines in packing-lists.
...
> setting PATH explicitly to
>
> /bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:${LOCALBASE}/bin:${LOCALBASE}/sbin
> before running @exec/@unexec
I'm thinking I'd like to impose a PATH for running @exec/@unexec
style lines in packing-lists.
Some people have their default path ignoring /usr/local, which is just
fine, but the packages expect things to run in a "correct" way, so currently
any local command requires /usr/local/bin/cmd to be run
Hi,
Craig R. Skinner wrote on Sat, Dec 28, 2013 at 09:16:23PM +:
> On 2013-12-19 Thu 13:43 PM |, Craig R. Skinner wrote:
>> Enhance rc.d/rc.subr with lowered/raised daemon running priority.
> Replace /etc/rc.d/ rc_renice=X with
> /etc/rc.conf.local _nice=X
I'd hate this, or anything similar,
On 2013-12-19 Thu 13:43 PM |, Craig R. Skinner wrote:
> Enhance rc.d/rc.subr with lowered/raised daemon running priority.
>
Take 2:
Replace /etc/rc.d/ rc_renice=X with
/etc/rc.conf.local _nice=X
$ fgrep _nice /etc/rc.conf.local
sshd_nice=-10
dhcpd_nice=15
inetd_nice=YES
greyscanner_nice=YES
> Date: Sat, 28 Dec 2013 15:42:12 -0500
> From: Brad Smith
>
> This moves rgephy(4) back to using RL_GMEDIASTAT to read the link/media
> status for re(4) attached Realtek PHY as was done before rev 1.25. rev
> 1.25 was to add support for external rgephy(4) attached to other MAC
> such as nfe(4),
This moves rgephy(4) back to using RL_GMEDIASTAT to read the link/media
status for re(4) attached Realtek PHY as was done before rev 1.25. rev
1.25 was to add support for external rgephy(4) attached to other MAC
such as nfe(4), but the PHY Specific Status register doesn't seem to
work properly with
maybe, one problem at a time?
first, whether there is actually a bug there, this patch fix it?
and then this removing genmask discussion
as i understand, unless you guys had already reached a conclusion once, there
might be no immediate result
and as blambert@ mentioned, whether it is really a b
IIRC, I'd talked to both claudio and sthen about removing genmask,
as it's unused and slightly nonsensical. Maybe we should just do
it, if there are actual bugs lurking therein?
On Sat, Dec 28, 2013 at 03:57:04AM +0800, Kieran Devlin wrote:
> re-send this patch, loop in claudio@
>
> maybe someone
18 matches
Mail list logo