On the other hand, in practice, the input size is also bounded. You deal not with arbitrarily long arrays, for example, since memory is not infinite.
So, I think, asymptotic time complexity is meaningful as long as the inputs we are considering can grow so much -- while remaining bounded -- that a linearithmic algorithm indeed outperforms, say, a quadratic one for a large and relevant class of inputs.
And that may be why computational models make those assumptions; but I'm not remotely sure.
Your own attitude towards life or criminals is not something worth considering when seriously pondering this question.
Society is a collection of individuals; everyone has different opinions and feelings on almost anything: at least when we discuss such sensible matters, we should rationalize our arguments, stripping any trace of subjectivity.
> I don't understand the great value placed on human life.
Coming to the case, you may not value your life very much, but we can't say the same for the criminal who is facing a death sentence.
Personally, I don't feel empathy for some criminals who consciously perpetrated atrocious crimes; I literally fail to care for them. Nevertheless, I can objectively understand that in a civilized country any human must be granted some undeniable rights.
> I see no reason not to put down humans who have malfunctioned.
Humans do not malfunction. Humans err, whether deliberately or not. They must have the right to redeem themselves. And even if they refused to, putting them to death would still be a miserable solution: it wouldn't mitigate the crime, nor would provide justice -- and I mean justice, not revenge. Indeed, it would be itself a crime.
Sorry, I'm not sure I've understood your question.
Do you mean encrypting the same way we encrypt using public key?
If so:
No, because as far as I can tell, when you "encrypt" a message with your public key you are in fact encrypting a random symmetric key which has been used in turn to encrypt the message. (Both ciphertexts must be sent to the recipient.)
As you may infer, if we use the same mechanism but encrypt using the private key, we just cannot ensure the authenticity of the message.
Git is cryptographically secure, but it’s not foolproof. If you’re taking work from others on the internet and want to verify that commits are actually from a trusted source, Git has a few ways to sign and verify work using GPG.
In Git 1.8.3 and later, “git merge” and “git pull” can be told to inspect and reject when merging a commit that does not carry a trusted GPG signature with the --verify-signatures command.
With the reverse-keyword convention we'd get "od", not "elihw", though.
The 'od' utility already existed, apparently, so Bourne opted for "done".
[edit: typos]