notabot

Yes, I think the chicken would need to be rotating, you should use both hands to spread the warmed area, and be prepared to administer more slaps than were calculated.

You could say you just go round and round hunting for it, but no matter how hard you try you just can't corner it.

Well, you could.

One must also consider the thermal conduction of the chicken. Slapping it, either once or multiple times, on a single area will impart energy to that area, raising the temperature there, but it will take time for that to disperse throughout the fowl. Thus will inevitably lead to the slapped area/areas being overcooked and the rest being dangerously undercooked. Losses to the environment must additionally be taken into account unless sufficient insulation is employed to mitigate this.

Bend them the other way. Start with all fingers open for zero, and curl them as needed. You only need to move them a bit, so even twenty (thumb and ring finger back, the others curled) isn't too hard.

Wait, it purged the entire ecosystem except trout, so what are the trout eating? Don't tell me we now have nuclear powered fish, the implications are terrifying. What happens if you're bitten by a radioactive trout? Do we get troutman, the superhero we neither want, need or deserve?

Don't go cold turkey, but if you reduce your intake slowly you can probably wean yourself off of it.

(Please don't do this)

Use a different encryption key for your swap partition, then put that in a file on your (encrypted) root. In /etc/crypttab, where you list the encrypted partition and the device name for the unencrypted view, you can list the key file too. That way the swap partition will be automatically decrypted during the boot process and before swap is enabled.

I believe there may be issues resuming from suspend doing this, but I've not tested that.

I'm notabot, 'Hi!'.

A really rough calculation (and I acknowledge I could be somewhat off here) suggests that if you contribute for 40 years, and get around 5% interest per year, you'd need to put in an average of €10,000 per year to reach €1,250,000. Working out average salary progression through a working life is left as an exercise for the interested reader, but assuming you're putting 10% of your salary into your pension, you'd need to be earning six figures to make that pension pot, so a drop to around €73,000 including the public pension could be hard to manage.

As I said, not so much can't retire, as can't retire at the same standard of living, especially as annuity payments wouldn't increase with inflation.

I agree that them having users' phone numbers isn't ideal. There are other identifiers they could use that would work just as well. However, both the client and server are open source, so you can build, at least the client, yourself. If you can content yourself that it does not leak your ID when sending messages, then you don't need to trust the server as it does not have the information to build a graph of your contacts. Sealed sender seems to have been announced in 2018, so it's had time to be tested.

Don't get me wrong, the fact they require a phone number at all is a huge concern, and the reason I don't really use it much, but the concern you initially stated was addressed years ago and you can build the client yourself to validate that.

You're correct that if you use the system the way it used to work they can trivially build that connection, but (and I know this is a big assumption) if it does now work the way they say it does, they do not have the information to do that any more as the client doesn't actually authenticate to the server to send a message. Yes, with some network tracing they could probably still work out that you're the same client that did login to read messages, and that's a certainly a concern. I would prefer to see a messaging app that uses cryptographic keys as the only identifiers, and uses different keys for different contact pairs, but given their general architecture it seems they've tried to deal with the issue.

Assuming that you want to use a publicly accessible messaging app, do you have any ideas about how it should be architected? The biggest issue I see is that the client runs on your phone, and unless you've compiled it yourself, you can't know what it's actually doing.

Strictly you're having to trust the build of the client rather than the people running the server. If the client doesn't send/leak the information to the server, the people running the server can't do anything with it. It's definitely still a concern, and, if I'm going to use a hosted messaging app, I'd much rather see the client built and published by a different group, and ideally compile it myself. Apart from that I'm not sure there's any way to satisfy your concerns without building and running the server and client yourself.