> whether it's code-coverage-based stress tests, symbolic execution, or static
> analysis. I think static analysis would do best here
What's the state of tools to find things like nested locks?
(Assume I'm willing to annotate the code to help.)
--
These are my opinions. I hate spam.
_
Warner Losh writes:
>
> On Feb 12, 2014, at 1:50 PM, Harlan Stenn wrote:
> > The conclusions I draw from the utter lack of any similar reports from
> > non-linux systems are:
> >
> > - either those kernels/libraries did not do leap-second processing, or
> > - they did and their code worked
> >
>
Back in the 1974 oil crisis the US made an 'emergency' change to its
DST schedual. I don't recall the legal mechanism used. It was likely
an executive order from the President.
But it most definitely was with less than 6 months notice so the legal
precedent is exists in the US.
I also have notic
On 12 Feb 2014, at 22:22, Clive D.W. Feather wrote:
> Ian Batten said:
>>> The easternmost point of the London district of Greenwich is a the
>>> intersection of two roads, Maze Hill and Charlton Way. The coordinates are
>>> 51° 28.509' N, 0° 0.602' E
>>
>> I'm not sure what you're using as a d
Ian Batten said:
>> The easternmost point of the London district of Greenwich is a the
>> intersection of two roads, Maze Hill and Charlton Way. The coordinates are
>> 51° 28.509' N, 0° 0.602' E
>
> I'm not sure what you're using as a definition of "district". SE2 0AT is in
> the
> Royal Borough
Brooks Harris said:
> D) Clarifying timezone guidelines, including standardizing
> "international date line", "UTC offset", and methods of "Daylight
> instantiation"
Um, timezones are a political matter pure and simple. Who do you think is
going to listen to you?
--
Clive D.W. Feather
Hal Murray said:
> I don't pay attention to summer time in Europe. How often do things change
> over there and/or how much notice do people get when the rules are changed?
The EU has standard rules defined in a Directive. The present Directive is
2000/84/EC and was published in the Official Jour
Warner Losh said:
>> Yes. I've never been able to understand why facing the guts of this problem
>> has been evaded. Its a great computer-science project - it should be fun!
>
> The problem stems not because one person can't climb the complexity hill to
> get it right: several have. The problem
On Feb 12, 2014, at 1:50 PM, Harlan Stenn wrote:
> The conclusions I draw from the utter lack of any similar reports from
> non-linux systems are:
>
> - either those kernels/libraries did not do leap-second processing, or
> - they did and their code worked
>
> Do you have different conclusions?
Warner Losh writes:
>
> On Feb 12, 2014, at 7:53 AM, Harlan Stenn wrote:
>
>> Warner Losh writes:
>>>
>>> On Feb 12, 2014, at 5:36 AM, Greg Hennessy wrote:
>>>
>> Um, that is false. All linux kernels did not crash, in fact NONE of
>> mine did.
>
> "all" here was an overst
> E) Leap seconds are tied to observations of the earth's spin, rather than
> predicted years in advance. With only 6 months warning for leap seconds,
> this produces operational difficulties for many environments that have
> burdensome change control policies.
What do those organizations do when
On Feb 12, 2014, at 11:22 AM, Rob Seaman wrote:
> Hi Warner,
>
> You’ll note that this particular email is addressed to you. Most
> contributions to this mailing list are not personally addressed. In those
> cases one might reasonably infer that other messages were intended as general
> con
On Feb 12, 2014, at 11:41 AM, Steve Allen wrote:
> On Wed 2014-02-12T11:22:57 -0700, Rob Seaman hath writ:
>>> On Feb 12, 2014, at 9:09 AM, Rob Seaman wrote:
Meanwhile, whatever discussions occur on this list should flow from
documented case studies:
http://www.cacr.
On 2014-02-12 09:46 AM, Warner Losh wrote:
On Feb 12, 2014, at 9:54 AM, Brooks Harris wrote:
On 2014-02-12 08:09 AM, Rob Seaman wrote:
There are many much more complex computer science challenges. In fact, the
entire purpose of these things called computers is to deal efficiently with
hella
On Wed 2014-02-12T11:22:57 -0700, Rob Seaman hath writ:
> > On Feb 12, 2014, at 9:09 AM, Rob Seaman wrote:
> >> Meanwhile, whatever discussions occur on this list should flow from
> >> documented case studies:
> >>
> >>
> >> http://www.cacr.caltech.edu/futureofutc/preprints/files/2_AAS%2013-50
Hi Warner,
You’ll note that this particular email is addressed to you. Most contributions
to this mailing list are not personally addressed. In those cases one might
reasonably infer that other messages were intended as general contributions to
a common forum.
> On Feb 12, 2014, at 9:09 AM,
On Feb 12, 2014, at 9:54 AM, Brooks Harris wrote:
> On 2014-02-12 08:09 AM, Rob Seaman wrote:
>>
>> There are many much more complex computer science challenges. In fact, the
>> entire purpose of these things called computers is to deal efficiently with
>> hellaciously complicated problems.
On 2014-02-12 08:03 AM, Warner Losh wrote:
On Feb 12, 2014, at 8:03 AM, Brooks Harris wrote:
On 2014-02-12 04:36 AM, Greg Hennessy wrote:
Um, that is false. All linux kernels did not crash, in fact NONE of
mine did.
"all" here was an overstatement, but the impact of the leap second
should nev
On 2014-02-12 08:09 AM, Rob Seaman wrote:
There are many much more complex computer science challenges. In fact, the
entire purpose of these things called computers is to deal efficiently with
hellaciously complicated problems. This problem ain't that intractable.
Yes. I've never been able
On 2014-02-12 07:47 AM, Warner Losh wrote:
The linux kernel has been touted by some of its proponents as the most tested
and verified kernel around. Some may quibble with this characterization, but if
not the most, certainly one of the most. And even so, this problem with leap
seconds managed
On Feb 12, 2014, at 9:09 AM, Rob Seaman wrote:
> On Feb 12, 2014, at 8:47 AM, Warner Losh wrote:
>
>> The linux kernel has been touted by some of its proponents as the most
>> tested and verified kernel around. Some may quibble with this
>> characterization, but if not the most, certainly one
On Feb 12, 2014, at 8:47 AM, Warner Losh wrote:
> The linux kernel has been touted by some of its proponents as the most tested
> and verified kernel around. Some may quibble with this characterization, but
> if not the most, certainly one of the most. And even so, this problem with
> leap sec
On Feb 12, 2014, at 8:03 AM, Brooks Harris wrote:
> On 2014-02-12 04:36 AM, Greg Hennessy wrote:
>>
Um, that is false. All linux kernels did not crash, in fact NONE of
mine did.
>>>
>>> "all" here was an overstatement, but the impact of the leap second
>>> should never be "your kernel
On Feb 12, 2014, at 7:53 AM, Harlan Stenn wrote:
> Warner Losh writes:
>>
>> On Feb 12, 2014, at 5:36 AM, Greg Hennessy wrote:
>>
>>>
> Um, that is false. All linux kernels did not crash, in fact NONE of
> mine did.
"all" here was an overstatement, but the impact of the leap
Warner Losh writes:
>
> On Feb 12, 2014, at 5:36 AM, Greg Hennessy wrote:
>
> >
> >>> Um, that is false. All linux kernels did not crash, in fact NONE of
> >>> mine did.
> >>
> >> "all" here was an overstatement, but the impact of the leap second
> >> should never be "your kernel crashes" even
On 2014-02-12 04:36 AM, Greg Hennessy wrote:
Um, that is false. All linux kernels did not crash, in fact NONE of
mine did.
"all" here was an overstatement, but the impact of the leap second
should never be "your kernel crashes" even if your personal kernels
didn't.
You should refrain from m
On Feb 12, 2014, at 5:36 AM, Greg Hennessy wrote:
>
>>> Um, that is false. All linux kernels did not crash, in fact NONE of
>>> mine did.
>>
>> "all" here was an overstatement, but the impact of the leap second
>> should never be "your kernel crashes" even if your personal kernels
>> didn't.
>
Um, that is false. All linux kernels did not crash, in fact NONE of
mine did.
"all" here was an overstatement, but the impact of the leap second
should never be "your kernel crashes" even if your personal kernels
didn't.
You should refrain from making inaccurate claims, it damages your
credi
28 matches
Mail list logo