> > Do you know where one can obtain a copy of this report? I did an
> > Internet search but couldn't find anything.
> me too
> Jeremiah: sorry if I insist (last time, promised!) but could you give us
> some more info about that report?
I am sorry for the delay, the Government shutdown really d
Chris Marusich writes:
> Hi Jeremiah,
>
> jerem...@pdp10.guru writes:
>
>> Atleast a single attempt in the last 60 years from any military on the
>> planet to deal with the risks written in the Nexus Intruder Report
>> published in 1958.
>
> Do you know where one can obtain a copy of this report?
Hi Jeremiah,
jerem...@pdp10.guru writes:
> Atleast a single attempt in the last 60 years from any military on the
> planet to deal with the risks written in the Nexus Intruder Report
> published in 1958.
Do you know where one can obtain a copy of this report? I did an
Internet search but couldn
> In other words, it's anecdotal.
True, it definitely was not a formal proof just data based upon real
world development with large teams of programmers and formal
specifications for correct behavior.
> Obviously, the flaw in this argument is that there exist much more
> efficient ways to add numb
Hi Jeremiah,
jerem...@pdp10.guru writes:
To truly solve that problem, we need bug-free compilers.
>>> Impossible for all but the simplest of languages as the complexity of
>>> implementing a compiler/assembler/interpreter is ln(c)+a but the
>>> complexity of implementing a bug-free compiler/
> Where are you getting those complexity expressions from?
Approximation of developer effort spent on single pass workflows and
bugfree libraries in the State of Michigan Welfware Eligibility System
extracted from it's ClearCase commit history. (Thank god, I finally got
them to convert to git after
Hi Jeremiah,
jerem...@pdp10.guru writes:
>> To truly solve that problem, we need bug-free compilers.
> Impossible for all but the simplest of languages as the complexity of
> implementing a compiler/assembler/interpreter is ln(c)+a but the
> complexity of implementing a bug-free compiler/assemble
> If you could add an "In-Reply-To:" header to your responses, that would
> be very helpful. It's easy to add it manually if needed: just copy the
> "Message-ID:" header from the original message and replace "Message-ID:"
> with "In-Reply-To:". As is, it's very difficult for me to keep track of
>
Hi Jeremiah,
If you could add an "In-Reply-To:" header to your responses, that would
be very helpful. It's easy to add it manually if needed: just copy the
"Message-ID:" header from the original message and replace "Message-ID:"
with "In-Reply-To:". As is, it's very difficult for me to keep trac
> I agree that a mathematical proof is what we should be aiming for, and
> the only kind of proof that I could trust in, in this scenario.
A formal proof would be just one piece used in building layers of trust,
each of them indpendent and reinforcing of each other like layers of
kevlar in a bulle
Hi Giovanni,
Giovanni Biscuolo writes:
> Mark H Weaver writes:
>
>> Giovanni Biscuolo writes:
>>> with a solid infrastructure of "scientifically" trustable build farms,
>>> there are no reasons not to trust substitutes servers (this implies
>>> working towards 100% reproducibility of GuixSD)
>
11 matches
Mail list logo
