509 karma · joined June 23, 2019
Ther is an algorithm in place where the rarest is downloaded. Also a priority list of older peers is implemented. Some protocol also request the chunk from muliple peers (kademlia).
Heat and nerve stimulation is also possible according to https://en.m.wikipedia.org/wiki/Safety_of_magnetic_resonance...
I also saw that with sports topics.
You can encode html in feeds. You just have to mark them as cdata.
[1] https://bitwarden.com/help/article/install-on-premise-linux/
https://www.postgresql.org/docs/current/ddl-rowsecurity.html
They have a rate limit for the amount of renewed certs. This doesn't apply if you don't reach their servers or don't get a cert.
But if you have a problem with a CA just switch to another which supports your bot (e.g. acme compliant CAs).
> The /dev/random device is a legacy interface which dates back to a time where the cryptographic primitives used in the implementation of /dev/urandom were not widely trusted. It will return random bytes only within the estimated number of bits of fresh noise in the entropy pool, blocking if necessary. /dev/random is suitable for applications that need high quality randomness, and can afford indeterminate delays.
and recommend:
> Linux 3.17 and later provides the simpler and safer getrandom(2) interface which requires no special files; see the getrandom(2) manual page for details.
Which book?
I see know that one can think of the domain model as most changed layer and if there is a bigger change it is because the domain model changes (e.g. business requirements). So a dependency from the domain model to other parts below are mostly fine.
If you add a property which shouldn't be public you have to separate them. For example in the domain model you have a user with email but do not want to expose the email.
Second argument: I usually create a simple struct for each method. For example I do not want, that they provide the id for post requests. I want to send the id on get requests so that they can send an update request with the id. I prefer only "non-null" arguments and as a bonus you get a clean (auto-generated) api documentation.
* How to disconnect the domain model from persistence.
Some solutions add the OR Annotations to the domain model. Some other map the domain model to persistence with a Mapper-layer.
But all of them have some constraints. For e.g. on a web api I receive a dto, map it to a domain model, map it to a persistence model and vice versa. Not much gained imho. In this example I would add the OR-annotations to the domain model and configure many-to-many by "text" so that they are not contained in the domain model.
What are your thoughts?