[clug] Man pages.
hal.ashburner at gmail.com
Mon Jul 27 05:11:47 UTC 2015
On 27 July 2015 at 15:10, Hal Ashburner <hal at ashburner.info> wrote:
> Those experts doing the writing would include the NSA. The idea they
> would be deliberately obfuscating in writing the standards used to be
> a whacky conspiracy tinfoil hat wearing zone. Used to be.
> There's a better link than this one but I can't dig it up.
> That's from 2007
> I'm trying to remember the name of the guy who (I think) used to be on
> the debian security team who tried to implement some of these crypto
> standards and gave up saying it couldn't be understood by him and
> other hackers nor crypto experts like Schneier.
> "Cryptographers have long suspected that the agency planted
> vulnerabilities in a standard adopted in 2006 by the National
> Institute of Standards and Technology and later by the International
> Organization for Standardization, which has 163 countries as members.
> Classified N.S.A. memos appear to confirm that the fatal weakness,
> discovered by two Microsoft cryptographers in 2007, was engineered by
> the agency. The N.S.A. wrote the standard and aggressively pushed it
> on the international group, privately calling the effort “a challenge
> in finesse.”
> “Eventually, N.S.A. became the sole editor,” the memo says."
> I think I liked the world better when this kind of thing was
> tinfoilhatsville. /me straightens brim.
> On 27 July 2015 at 14:47, Paul Harvey <csirac2 at gmail.com> wrote:
>> On 27 July 2015 at 12:49, Lana Brindley <mail at lanabrindley.com> wrote:
>>> On 27/07/15 11:40, Scott Ferguson wrote:
>>>> If he was referring to the content of man pages. Determining the
>>>> readability of man pages (or any technical documentation) is not as
>>>> simple as assessing it by readability tests designed for non-technical
>>>> writing - for obvious reasons.
>>> I know you say it's obvious, but I don't understand. Why should tech
>>> comms be held to a different level of readability to non-tech comms?
>>> Can you expand?
>> This is going off-topic, but I've always assumed that efficient
>> communications must choose an audience.
>> I used to deal with a lot of RDF/OWL/Ontology data/actor/system
>> modeling stuff. Consider the concept of
>> https://en.wikipedia.org/wiki/Reification - it seems simple enough,
>> but following a conversation takes some getting used to.
>> Although we can simplify vocabulary, this won't necessarily help in
>> communicating concepts. I once read an interesting New Scientist
>> article about a genetics researcher trying to explain her work back
>> home to a native Urdu speaker. There was no choice but to introduce a
>> new word, "DNA", before she could even begin to talk about what she
>> does every day.
>> Does that excuse crappy technical documentation generally? No. But I
>> do believe there are efficient technical communications which require
>> that readers unfamiliar with the subject matter must decide if they
>> actually need to understand a given document, or face the prospect of
>> learning a few things as they digest it.
>> Another example is RFCs (Request for Comments) hosted by the IETF
>> (Internet Engineering Taskforce). Some are fantastically readable,
>> especially when the authors want to appeal to a wide audience (Eg. web
>> developers). But take the RFC describing TLS 1.2 (one of the things
>> behind the "secure" part of the https:// protocol):
>> This is a document written for (and by) people who are *creating* TLS
>> protocol implementations, of which there must be hardly more than
>> hundreds of humans doing this at any one time on this planet. Beyond
>> that, perhaps thousands who need this level of detail. The rest of us
>> are expected to use more approachable beginner/intermediate texts
>> which distill this subject matter down to a more widely accessible
>> And now I see that my own writing gets a slightly lower readability
>> score than RFC5246. Perhaps I'm the wrong person to be talking about
>> linux mailing list
>> linux at lists.samba.org
More information about the linux