From: dekkzz78@gmail.com
To: help-gnu-emacs@gnu.org
Subject: Re: Re: CVE-2017-14482 - Red Hat Customer Portal
Date: Fri, 29 Sep 2017 15:59:21 +0100 [thread overview]
Message-ID: <20170929145921.GA5297@TP-x61s.localdomain> (raw)
In-Reply-To: <83a81d8ylf.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 3610 bytes --]
On 09/29, Eli Zaretskii wrote:
>> From: Mario Castelán Castro <marioxcc.MT@yandex.com>
>> Date: Tue, 26 Sep 2017 09:46:46 -0500
>>
>> > "correct" means that the client (the people who required the software)
>> > says that the program fulfills his requirements. Sometimes you need to
>> > wait an infinite amount of time for obtaining client's approbation :-)
>>
>> The same answer applies: If a client either provides himself or accepts
>> a formula in formal logic as a description of his requirements, then
>> yes, we can prove that a program is correct according to this concept.
>>
>> If the client can not provide an *absolutely accurate* description (this
>> is necessarily a specification in formal logic) of what his requirements
>> are, then we can not assure the client that the program meets his
>> requirements. This is not a fault of the programmer, but of the client
>> for being vague about what his requirements are.
>
>Good luck finding many clients that can provide such a set of
>requirements. Most of the projects I deal with in my daytime job have
>to do with clients that cannot even provide _in_formal requirements,
>and depend on me and my team to do that for them.
Ouch - there's a project doomed from the start.
>> > […] We must provide what is requested from us, in
>> > terms of functionality, performance and cost […]
>>
>> Somebody has to take a decision between cheap software and reliable
>> software. Those are mutually exclusive.
>
>The world is not black-and-white, it's an infinite set of gray shades.
>If you are running a practical operation that needs to satisfy clients
>and be self-sustaining, you will have to choose one of those shades.
>You seem to be advocating the "reliable software" extreme, which,
>according to your definitions, is unreachable in any practical project
>of a large enough size. This is a kind of academic solution that does
>not translate well to any software engineering practices that lead to
>a delivery soon enough for clients to want to order your solutions.
>
>IOW, I'm firmly with Óscar here.
>
>> The predominating choice is cheap software. As evidence for this claim I
>> note the very high frequency of bug reports including security
>> vulnerabilities.
That's more to with poor teaching & understanding of how to code securely.
>I think you are misinterpreting the reasons for those bugs and
>vulnerabilities. The real reasons are the tremendous complexity of
>software we are required to produce nowadays, and the respectively
>inadequate level of formal-proof technologies that prevent their use
>in large-scale projects.
>
>IOW, we are simply trying to solve problems that are in principle
>insoluble with the current technology. So what we get are solutions
>that are 90% reliable, and the rest are bugs and vulnerabilities.
>
>> I have spent already enough time addressing your misconceptions. If you
>> reply to this message with even more misconceptions, I will not reply
>> because I am unwilling to spend even more time explaining what you
>> should already know. It is *YOUR* task to make sure you know what you
>> are talking about (and you have failed so far), not mine!.
>
>Please consider dropping your arrogant style and allow that others
>come into this discussion with some level of experience and knowledge,
>which should be respected as valid, instead of discarding it. If you
>disregard engineering practices, then your pure science is not
>interesting, at least not to those who have practical problems to
>solve every day.
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2017-09-29 14:59 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-21 21:51 CVE-2017-14482 - Red Hat Customer Portal ken
2017-09-21 22:03 ` Kaushal Modi
2017-09-21 23:07 ` ken
2017-09-22 7:37 ` Alberto Luaces
2017-09-22 7:48 ` Emanuel Berg
2017-09-22 20:12 ` Mario Castelán Castro
2017-09-22 22:14 ` Emanuel Berg
2017-09-24 2:08 ` Mario Castelán Castro
[not found] ` <mailman.1063.1506218941.14750.help-gnu-emacs@gnu.org>
2017-09-24 6:47 ` Emanuel Berg
2017-09-24 13:38 ` Mario Castelán Castro
2017-09-24 14:42 ` Óscar Fuentes
2017-09-24 14:54 ` tomas
2017-09-26 18:57 ` Narendra Joshi
2017-09-24 23:06 ` Emanuel Berg
2017-09-25 21:23 ` Mario Castelán Castro
2017-09-25 21:49 ` Emanuel Berg
2017-09-26 1:43 ` Mario Castelán Castro
2017-09-26 2:17 ` Emanuel Berg
2017-09-25 21:11 ` Mario Castelán Castro
2017-09-25 23:58 ` Óscar Fuentes
2017-09-26 14:46 ` Mario Castelán Castro
2017-09-26 23:31 ` Óscar Fuentes
2017-09-29 20:21 ` Mario Castelán Castro
2017-09-29 12:43 ` Eli Zaretskii
2017-09-29 14:59 ` dekkzz78 [this message]
2017-09-29 16:51 ` Óscar Fuentes
2017-09-29 17:20 ` Emanuel Berg
2017-09-29 18:27 ` Óscar Fuentes
2017-09-29 19:45 ` Emanuel Berg
2017-09-29 20:06 ` Óscar Fuentes
2017-09-29 23:24 ` Emanuel Berg
2017-09-29 18:03 ` Eli Zaretskii
2017-09-24 23:07 ` Emanuel Berg
2017-09-23 10:05 ` Charles A. Roelli
2017-09-23 12:53 ` Óscar Fuentes
2017-09-23 13:12 ` Eli Zaretskii
2017-09-23 17:18 ` Glenn Morris
2017-09-23 17:34 ` Eli Zaretskii
2017-09-23 20:50 ` Yuri Khan
2017-09-24 2:53 ` Eli Zaretskii
2017-09-24 7:13 ` Philipp Stephani
2017-09-24 18:29 ` Robert Thorpe
2017-09-29 8:17 ` Eli Zaretskii
2017-09-29 20:28 ` Stefan Monnier
2017-09-29 23:28 ` Emanuel Berg
2017-10-03 0:52 ` Stefan Monnier
2017-10-03 1:04 ` Emanuel Berg
2017-09-29 7:11 ` Eli Zaretskii
[not found] ` <mailman.1068.1506237251.14750.help-gnu-emacs@gnu.org>
2017-09-24 7:48 ` Emanuel Berg
2017-09-25 21:26 ` Glenn Morris
2017-09-25 22:02 ` Emanuel Berg
2017-09-25 22:08 ` Ludwig, Mark
2017-09-26 5:50 ` Emanuel Berg
2017-09-26 13:40 ` Ludwig, Mark
2017-09-26 17:46 ` Philipp Stephani
2017-09-26 19:00 ` Ludwig, Mark
2017-09-29 13:23 ` Eli Zaretskii
2017-09-29 9:48 ` Eli Zaretskii
2017-09-26 18:44 ` Narendra Joshi
2017-09-26 18:51 ` Philipp Stephani
[not found] ` <mailman.988.1506161159.14750.help-gnu-emacs@gnu.org>
2017-09-24 6:31 ` Emanuel Berg
2017-09-22 16:40 ` ken
2017-09-22 19:07 ` Emanuel Berg
2017-09-23 20:27 ` Bob Proulx
[not found] ` <mailman.1053.1506198486.14750.help-gnu-emacs@gnu.org>
2017-09-24 6:38 ` Emanuel Berg
2017-09-24 17:17 ` Maxim Cournoyer
2017-09-24 22:38 ` Emanuel Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170929145921.GA5297@TP-x61s.localdomain \
--to=dekkzz78@gmail.com \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).