Also, the author did not spend two days. he spent 17 minutes and then did the math to calculate the block hash rate.

> Doing one round of SHA-256 by hand took me 16 minutes, 45 seconds. At this rate, hashing a full Bitcoin block (128 rounds)[3] would take 1.49 days, for a hash rate of 0.67 hashes per day

The Supreme Court of India declared the right to privacy a fundamental right under Article 21 - as the same level as right to life and personal liberty. https://www.eff.org/deeplinks/2017/08/indias-supreme-court-u...

This ruling was one the the landmark rulings in recent times, and a true David vs Goliath story - where a small group of privacy activists won against mandatory Aadhaar.

While it is true that right to privacy implementation remains patchy, there is growing awareness around privacy - both from government, and against large corporations. For example, half of my contact list is now on Signal and last week I had more chats on Signal than on WA.

Signal has reproducible builds for Android. https://signal.org/blog/reproducible-android/

Does that help in any way to verify that they do not store data on their servers?

My understanding: If you verify the safety numbers in person, then I believe you can be confident that it's E2E encrypted for that conversation. If the safety numbers are different, then there could be a nefarious actor listening in.

Someone please correct me if I'm wrong.

Edit: That being said, I believe they could still record IPs, as well as the destination and timestamps of each message.

If they were storing that it would have been produced when they were forced to produce all data relevant to the case.

Agreed. Just pointing out what information they have access to if they wanted to start logging as much as they could.

Sadly I don't see any way to prove that over time except through periodic court orders :)

It only helps verify what data the client sends to their servers, not what fraction of that data is stored on their servers. They could be (but probably aren't; see other comments) storing e.g. information about how often you connect and the volume of data that passes through their servers.

There are geo based account bans. I have seen a few from India with a message similar to "This account has been withheld in India due to a legal request"

Example is this account: https://twitter.com/gurmeetramrahim

Subtraction makes sense here as you are trying to find the excess yield of equity over dividend.

A yield of bond: 0.5, equity 4 vs bond: 1, equity: 4.5 doesn't change his argument, but changes the ratio significantly.

Also, Anybody who has received an organ transplant is immunosuppressed. They take immunosuppressive drugs so that the transplanted organ is not rejected.

It would be so nice if those people could have access to a coctail of synthetic antibodies that gave some protection to covid-19, the flu and others. Or perhaps a generic antibody that protects against most viruses(unlikely, given such an atibody does not exist in nature).

Antibodies don't themselves help fight infections; their role is simply to identify dangerous pathogens to white blood cells. In immunosuppressed patients, those cells often aren't present (or aren't responding properly), so adding antibodies wouldn't help.

Antibodies also initiate the complement cascade and can thus kill cells directly.

It is funny Google is banning Paytm claiming "Gambling", when their competing app Google Pay literally gives away a scratch card (with variable, including zero payoffs - a literal scratch card) with every transaction in their app.

Has there been any significant success stories wherein people made a fair return on their time under the "fund me" model?

Django ORM is ActiveRecord pattern, right?

This is what I would use

   Book.objects.filter(author__nationality="Italian", author__state="deceased").values("isbn")

This is

- Is one single DB query.

- Completely obvious way to describe what I want to do.

- Only pulls the fields which are needed from the DB.

If you are claiming "the troublesome acriverecord pattern" you need to provide specifics of what can't be done, rather than claim "Don't look too deeply into the code samples for specifics though"

I think as soon you use "values" it is no longer the ActiveRecord pattern since the result is not an object instance representing a single row in the table.

I never read a proper specification of ActiveRecord, but it could be that a "pure" implementation doesn't allow for joins? Hence the weird looking example with the nested for loop, which variations of I have seen plenty in real world code. Mostly by people that don't sufficiently understand the ORM or SQL, not because they were sticking to a pattern though.

In your example it is obvious what happens in this simple example, but as soon the joins become more complex, it becomes in my opinion quite unwieldy and non obvious what the resulting SQL will be. I had multiple performance problems in the past because of the queries the ORM generated or with memory/cpu usage on the app side.

That's fine. For 95% of the queries you need, ActiveRecord-ish implementations are perfectly performant, and super readable. For the rest, they allow you to drop down to the SQL layer and specify exactly what you want or need.

Yes, that is what we do and what I like about SQLAlchemy for Python. We use the ORM for like 90% of cases and drop down to its SQL abstraction underneath the ORM.

The last time I used Django a couple of years ago that was one of the bigger pains for me: It was either the Django ORM capabilities or raw SQL, not much in between. Or maybe I was just unaware of how to do it better.

Python designers have some thoughts on this :)

$ python -c "import this" | grep purity Although practicality beats purity.