Add a -R flag to tftpd for a read only mode. This allows for a tighter
pledge than currently possible because by default existing files can be
overwritten (but no new files created). Perhaps read only should be the
default since it is surprising that tftp can overwrite by default.
- Matthew Martin
On Thu, Jan 21, 2016 at 01:57:28AM +0100, Stefan Sperling wrote:
> On Wed, Jan 20, 2016 at 10:16:53PM +0100, Stefan Sperling wrote:
> > On Wed, Jan 20, 2016 at 10:04:11PM +0100, Stefan Sperling wrote:
> > > This diff makes us keep track of changes in the network's HT protection
> > > settings. Thes
Below the conversion from uiomovei() to uiomove() for bktr. The patch
also replaces two occurrences of uio->uio_iov->iov_len with
uio->uio_resid. I don't see a reason why bktr should inspect iov_len
directly.
Index: dev/pci/bktr/bktr_core.c
=
Hi Jonathon,
Thanks a lot for taking your time to test this.
On 24 January 2016 at 06:49, Jonathon Sisson wrote:
> On Sat, Jan 23, 2016 at 02:18:17PM -0800, Jonathon Sisson wrote:
>> Speaking of testing, is there any particular area non-devs could
>> assist with at this time? Gathering dmesgs f
On Sun, Jan 24, 2016 at 03:05:28AM -0600, Matthew Martin wrote:
> Add a -R flag to tftpd for a read only mode. This allows for a tighter
> pledge than currently possible because by default existing files can be
> overwritten (but no new files created). Perhaps read only should be the
> default sinc
On Fri, 22 Jan 2016 22:46:39 +0100 (CET)
Mark Kettenis wrote:
> Firefox makes a lot of concurrent malloc(3) calls. The locking to
> make malloc(3) thread-safe is a bit...suboptimal. This diff makes
> things better by using a mutex instead of spinlock. If you're running
> Firefox you want to tr
On Sat, Jan 23, 2016 at 08:48:22PM +0100, Reyk Floeter wrote:
> On Sat, Jan 23, 2016 at 12:39:19PM -0600, Brent Cook wrote:
> > I'm going with this instead. That way it works like the manual
> > specifies already (-v enables logging debug messages)
> >
>
> Yes, the -v flag is better, but see below.
On Sun, Jan 24, 2016 at 02:16:37PM +0100, Mike Belopuhov wrote:
> Hi Jonathon,
>
> Thanks a lot for taking your time to test this.
>
No, thank you guys for all of the work you're doing to get
this working. I'm just a user heh.
>
> Trying newer kernels would be the most helpful. I've just enabl
On 24 January 2016 at 20:55, Jonathon Sisson wrote:
> On Sun, Jan 24, 2016 at 02:16:37PM +0100, Mike Belopuhov wrote:
>> Hi Jonathon,
>>
>> Thanks a lot for taking your time to test this.
>>
> No, thank you guys for all of the work you're doing to get
> this working. I'm just a user heh.
>
>>
>>
On 24 January 2016 at 20:47, Adam Wolk wrote:
> On Fri, 22 Jan 2016 22:46:39 +0100 (CET)
> Mark Kettenis wrote:
>
>> Firefox makes a lot of concurrent malloc(3) calls. The locking to
>> make malloc(3) thread-safe is a bit...suboptimal. This diff makes
>> things better by using a mutex instead o
On 23.1.2016. 23:29, Adam McDougall wrote:
> Hello,
>
> I have a few Dell servers which I've installed OpenBSD for testing
> but ran into a problem with keystroke loss on the console when used
> through the Dell iDRAC remote graphical console. Surprisingly it
> operates perfectly fine in the inst
On Sat, Jan 23, 2016 at 10:21:38PM +, Michael Savage wrote:
> The page at http://www.openbsd.org/opensmtpd/faq/example1.html doesn't
> display correctly because browsers try to interpret /
> as HTML tags. This patch replaces < and > with > and <.
This fix was committed by TJ. I also fixed two
On Sun, Jan 24, 2016 at 09:08:32PM +0100, Mike Belopuhov wrote:
> On 24 January 2016 at 20:55, Jonathon Sisson wrote:
> > On Sun, Jan 24, 2016 at 02:16:37PM +0100, Mike Belopuhov wrote:
> >> Hi Jonathon,
> >>
> >> Thanks a lot for taking your time to test this.
> >>
> > No, thank you guys for all
On 01/22/16 22:46, Mark Kettenis wrote:
> Firefox makes a lot of concurrent malloc(3) calls. The locking to
> make malloc(3) thread-safe is a bit...suboptimal. This diff makes
> things better by using a mutex instead of spinlock. If you're running
> Firefox you want to try it; it makes video wat
On Sun, Jan 24, 2016 at 01:22:20PM -0800, Jonathon Sisson wrote:
> On Sun, Jan 24, 2016 at 09:08:32PM +0100, Mike Belopuhov wrote:
> > I haven't seen that on my test box (not AWS), but maybe reverting
> > the minimum number of rx slots back to 32 can help?
> >
> > http://cvsweb.openbsd.org/cgi-bin
tech@,
I've uploaded a few of the dmesgs gathered to dmesgd.nycbug.org:
http://dmesgd.nycbug.org/index.cgi?action=dmesgd&do=index&fts=Jonathon
Currently I have m4.10xlarge, c4.8xlarge, m3.medium, and t2.nano
uploaded for perusal.
I noticed some new output in the m4.10xlarge console output here:
tl;dr version: openbsd.cs.toronto.edu anoncvs and cvsync users need to
start using anon...@obsdacvs.cs.toronto.edu and
cvsync://obsdacvs.cs.toronto.edu instead.
Full story:
===
Important notice for those using the mirror at University of Toronto:
Thanks to the OpenBSD Foundation and its
Hi Matthew,
Matthew Martin writes:
> On Sun, Jan 24, 2016 at 03:05:28AM -0600, Matthew Martin wrote:
>> Add a -R flag to tftpd for a read only mode. This allows for a tighter
>> pledge than currently possible because by default existing files can be
>> overwritten (but no new files created). Pe
I noticed those a while ago, the #if 0 is there since the beginning.
Can't see the point in keeping this as is.
ok?
Index: libgen.h
===
RCS file: /cvs/src/include/libgen.h,v
retrieving revision 1.7
diff -u -p -p -u -r1.7 libgen.h
--
On Sun, Jan 24, 2016 at 9:14 PM, Jérémie Courrèges-Anglas
wrote:
> I noticed those a while ago, the #if 0 is there since the beginning.
> Can't see the point in keeping this as is.
>
> ok?
ok guenther@
On 2016/01/25 04:32, Jérémie Courrèges-Anglas wrote:
>
> Hi Matthew,
>
> Matthew Martin writes:
>
> > On Sun, Jan 24, 2016 at 03:05:28AM -0600, Matthew Martin wrote:
> >> Add a -R flag to tftpd for a read only mode. This allows for a tighter
> >> pledge than currently possible because by defaul
> From: "Peter N. M. Hansteen"
> Date: Sun, 24 Jan 2016 23:10:41 +0100
>
> On 01/22/16 22:46, Mark Kettenis wrote:
> > Firefox makes a lot of concurrent malloc(3) calls. The locking to
> > make malloc(3) thread-safe is a bit...suboptimal. This diff makes
> > things better by using a mutex inste
22 matches
Mail list logo