> # cd /usr/src/usr.sbin/ntpd/
> # for i in $(find . -name "*.[ch]"); do cat $i >> /root/allcode; done
> # egrep -v '[:blank:]*/?\*' /root/allcode | grep -v "^ *$" | wc -l
> 2898
> > $ for i in $(find . -name "*.[ch]"); do cat $i >> allcode; done
> > $ egrep -v '[:blank:]*/?\*' allcode | g
Using the same test on OpenNTPD from OpenBSD-STABLE:
# cd /usr/src/usr.sbin/ntpd/
# for i in $(find . -name "*.[ch]"); do cat $i >> /root/allcode; done
# egrep -v '[:blank:]*/?\*' /root/allcode | grep -v "^ *$" | wc -l
2898
Quite a difference indeed.
On Fri, Dec 19, 2014 at 7:26 PM, trondd
On Fri, Dec 19, 2014 at 8:22 PM, Theo de Raadt
wrote:
> whereas ntp.org's codebase is reportedly 100,000 lines of
> unknown or largely unused code
>
That made me curious. Is it that bloated?
$ for i in $(find . -name "*.[ch]"); do cat $i >> allcode; done
$ egrep -v '[:blank:]*/?\*' allcode | g
The ntp daemon included in OpenBSD is our own openntpd, written
from scratch.
openntpd is not vulnerable.
Around 10 years ago it was written by Henning, at my request because
the ntpd source code scared the hell out of us. At the time
communications with the ntp team showed they had little inter
On 17.12.2014. 6:34, Philip Guenther wrote:
Uh, ACPI *requires* that C1 exist. The halt instruction is defined as
entering C1, so not having C1 would mean your CPU lacks a basic
manadatory ia32 instruction. Hopefully the BIOS docs explain that
you're just disabling "deep" C-states or something
On 12/19/14 18:12, Ted Unangst wrote:
On Fri, Dec 19, 2014 at 13:04, Stuart Cassoff wrote:
On 12/19/14 07:18, Stuart Cassoff wrote:
$ pstat -T
221/7030 open files
Segmentation fault
I suppose more info from me is desired.
I think that was sufficient. It should be fixed now.
Hi Ted,
It's
On Fri, Dec 19, 2014 at 13:04, Stuart Cassoff wrote:
> On 12/19/14 07:18, Stuart Cassoff wrote:
>> $ pstat -T
>> 221/7030 open files
>> Segmentation fault
>
> I suppose more info from me is desired.
I think that was sufficient. It should be fixed now.
On 12/19/14 07:18, Stuart Cassoff wrote:
> $ pstat -T
> 221/7030 open files
> Segmentation fault
I suppose more info from me is desired.
$ gdb pstat
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to c
> Date: Fri, 19 Dec 2014 23:41:56 +1000
> From: Jonathan Matthew
>
> On Thu, Dec 18, 2014 at 11:14:54PM +0100, Frederic Nowak wrote:
> > Hi!
> >
> > The diff for extracting memory ranges from ACPI was obviously not tested
> > with ACPI disabled...so we definitely have to check if the values in
>
On 19/12/14(Fri) 08:04, David Higgs wrote:
> Split upd_update_sensors() behavior to gather all values prior to updating
> sensor contents.
>
> Because sensors were updated in report_ID order, it could take multiple
> passes of upd_refresh() to update some sensors. Specifically,
> battery-relat
Hi,
the following diff adds support for source-hash and random modes to
relayd's redirections. It depends on the latest pf change.
Example:
---snip---
redirect foo {
listen on 0.0.0.0 port 8080
forward to check tcp port 80 mode source-hash
# forward to check tcp port 80 m
On Thu, Dec 18, 2014 at 11:14:54PM +0100, Frederic Nowak wrote:
> Hi!
>
> The diff for extracting memory ranges from ACPI was obviously not tested
> with ACPI disabled...so we definitely have to check if the values in
> pcimem_range make some sense. The diff below now uses the old values in
> case
Split upd_update_sensors() behavior to gather all values prior to updating
sensor contents.
Because sensors were updated in report_ID order, it could take multiple passes
of upd_refresh() to update some sensors. Specifically, battery-related sensors
“prior” to a change in BatteryPresent would
$ pstat -T
221/7030 open files
Segmentation fault
On Fri, Dec 19, 2014 at 7:17 AM, Martin Pieuchot wrote:
> Hello David,
>
> On 18/12/14(Thu) 00:45, David Higgs wrote:
>> While my device does not seem to provide AtRateTimeToFull or
>> AtRateTimeToEmpty, it does have RunTimeToEmpty. Then I found that
>> SENSOR_TIMEDELTA values are in nanosecond
Hello David,
On 18/12/14(Thu) 00:45, David Higgs wrote:
> While my device does not seem to provide AtRateTimeToFull or
> AtRateTimeToEmpty, it does have RunTimeToEmpty. Then I found that
> SENSOR_TIMEDELTA values are in nanoseconds and that scaling for them was
> never implemented correctly.
>
16 matches
Mail list logo