cpuShares is the relative weight wrt other apps. This is used when
there is contention for CPU. If we want this, maybe we implement
a UI where we show all the apps and let the user re-order them.
As it stands, it is confusing.
cpuQuota is a more straightforward "hard limit" of the CPU% that you
want the app to consume.
Can be tested with : stress -c 8 -t 20s
the secp384r1 is not getting accepted by a few mail servers.
the upstream server is TLS 1.2 and advertises:
{0xC0, 0x2C} TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
{0xCC, 0xA9} TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
{0xC0, 0x2B} TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
{0xC0, 0x24} TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
{0xC0, 0x23} TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
{0xC0, 0x09} TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
the connection fails with:
client connection error: Error: C0E703901F7F0000:error:0A0000C1:SSL routines:tls_post_process_client_hello:no shared cipher:../deps/openssl/openssl/ssl/statem/statem_srvr.c:2241:
node's current cipher list is https://nodejs.org/api/tls.html#modifying-the-default-tls-cipher-suite.
It says default cipher suite prefers GCM ciphers. ECDHE-ECDSA-AES256-GCM-SHA384 and ECDHE-ECDSA-AES128-GCM-SHA256
are the valid TLS 1.2 options but neither of these are selected.
the public key strength is somehow tied to cipher selection, I am not entirely sure how. from what i remember
`ecdsa_secp384r1_sha384` was listed in signature_algorithms extension.
Note that one document I found said that exchange server has a further _P256 and _P384 to cipher combinations.
Which suggests to me that one can also select specific curve+cipher combination.
anyway, with this curve, atleast the connection work with TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
Currently, we only have one field for the name. The first part is
first name. The rest is last name. Obviously, this won't work in all
cases but is the best we can do for the moment.
