And now you know why i did not want to be the one to explain TPM, because i
often make little mistakes, such as typo. Or, for example, quoting only
half of a sentence as Jaromil points out.

Or assuming that, like myself, the readers of this list have spent a
life-time studying operating systems' design and implementation, and are
aware that a cryptographic co-processor is treated by the OS like any other
resource; ( IE: RAM, CPU cycles ) doled out to applications in metered
quantities. (Not a magic bullet from the MPAA)

A TPM / cryptographic co-processor is a general purpose hardware that can
be used for good or evil. It does not makes sense to ignore this technology
in the hopes that no one else will mis-use it.
Do you think that if the guys on the Devuan mailing list ignore the issue
that will prevent other corporate interests from misusing the technology?
No, better put it to good use first.

IMO, the RMS article linked by Jaromil is exactly the kind of
fear-mongering i warned against in a previous post:

>That said, any one should recognize an illogical argument that goes along
these lines:
>"Crypto primitives such as encryption allow "locking" information and thus
restricting access to it."
>It does not mean we should abandon encryption or let arbitrary entities
lock our info!

The topic of the article is, in fact, not TPM but some imaginary technology
called "Treacherous Computing." I think its fine to use some fictitious
technology for a sensational article for the "general public." But, to
assume that OS developers would be at that level of understanding is kind
of a slap-in-the-face. Treacherous Computing is a sensational fictitious
idea that does not equate to TPM. How about link to an RFC or technical
document that describes some feature you have a problem with?

Instead of rehashing nightmare scenarios, id like to invite you into my
day-dream:
Devuan makes headlines news as the first OS to use a TPM to prevent the
installation of any DRM software or any software that does not respect the
user's freedoms.