I think we can have both architectures Monolith and Microservices peacefully co-existing, with their own pros and cons.

Well, lets assume N = 999, then N^2 = 998001, so nowhere near the number of atoms in the universe, which is estimated to be about 10^80.

I think the person you're replying to meant 2^N based on the context. They're saying you have to account for every possible combination of services being down.

"Nintendo ... rolls their own emulator(s) ... rather than using existing open source ones"

Wouldn't it be possible to reverse engineer these emulators? Maybe the official Nintendo SNES emulator has all the right S-PPU1/2 values in it.

Doubtful. Byuu’s emulator is already much more accurate than Nintendo’s own.

Are there any protection mechanism against that? Something like, even if you are being tortured you cannot provide the access to anyone else?

Don't take the laptop with you.

At this point setting up a secure connection to a device in a secure location is way easier than trying to protect your data against someone with physical access.

You can also get your collaborators to revoke access if you fear you might be 'compromised', although ultimately it's hard to protect a system against yourself.

I believe Truecrypt supported a feature where different passwords would unlock different partitions in a volume. So someone could ask you to input the password for BadBoy.tc, and if you enter password1, then you get say the data they actually want. But if you enter password2, it mounts a different part of the file which gives the appearance that you unlocked the whole thing. So, you could stage a dummy partition that has false but convincing data and hopefully fool any captors.

Yes, but:

1) they might not believe you, and

2) that’s still true even if the reason you don’t have a key is because you don’t actually have a secret encrypted partition — or whatever — to supply a decryption key for

So the best thing to do is avoid being in a situation where someone is allowed to do that in the first place.

This is interesting. This also means that using encryption or anything that can plausibly make someone even slightly suspect you're using encryption (even if you are not) can make your situation worse, with certain classes of enemies.

I'm sure advanced configurations with well-crafted decoys and steganography can help combat that, but as we can see, encryption can only take you so far and it's only one element of the picture.

Plausible deniability, like hidden containers in TrueCrypt?

That's a double edged sword though - imagine you give up, surrender the password and are then being asked to unlock a hidden volume, which you don't have.

Encrypt with two keys, one that you know and one that a trusted third party , knows. When you reach your destination, establish secure contact with the third party and have them share their key.

I think one method would be to ensure you don't have the full key, i.e. you have some select friends, each that have part of the key (with some redundancy) - all unaware of one another and potentially all unaware that they even have part of the key.

Then you position your friends over multiple jurisdictions so that they cannot legally compel all of them to play along.

Sharded secrets... you only have one part of a key or keys needed to decrypt some data so even extracting that from you by torture will not suffice. Of course this isn't always practical.

“They” (whoever they are) can torture more than one person at a time.

The trick is to ensure you are never near all the people who know the secret when there is the possibility of trouble. That makes kidnapping everyone harder.

Of course if you really worry about such things you shouldn't be trusting the other people you are working with either...

Presumably the other key holders are in a different jurisdiction.

If you're talking about protection for the people that may be captured with the help of the data you may have on your computer, yes.

Otherwise, no. When they have you they can just torture you to death for whatever reason or no reason at all.

There is no doubt that the PCI-DSS is a farce.

Why pyhton 2.7? He's dead, Jim.

Category theory

Answers like this might be useful if you explained where it is useful and how it might benefit people.

This does not sound nice at all. What on Earth correctness has to do with avoiding C++?

Since you quoted me, I'd like to clarify my statement. When I said:

> Rust is very deliberately designed to address safety and correctness issues that exist in a style of programming that's just completely orthogonal to what I do.

this doesn't in any way imply that Rust addresses correctness issues that all C++ code is subject to. Rather, Rust addresses correctness issues that are endemic in particular kinds of C++ code, which is qualitatively different from the code I find myself writing (probably much more due to domain specifics than any personal skill). Therefore, in that context, I don't see much reason to believe Rust will on average produce better results than C++ in terms of correctness, even though it might very well do so in a different context (like the context it was actually designed for).

That being said, I obviously do care about correctness. If I had reason to believe that Rust will on average lead to satisfactorily correct code with less effort than it would take me to achieve the same level of correctness in C++, absent any other major contraindications I would switch languages. Personally, I would be rather happy to switch away from C++ - unfortunately, most alternatives so far look considerably worse given the specific context I operate in.

Rust has a lot of correctness features that are useful, and some not related to memory safety, for example 3 that come to mind:

options and results instead of null pointer or using bit flags to indicate invalid states (a recent sudo exploit would not have happened in a language with option types)

everything is an expression so you do not have to create uninitialized variables and then set them later inside a switch or if statement.

much less (no?) undefined behavior

for someone working in a particular C++ niche who has developed strategies to avoid all of these problems already, then switching to Rust certainly may not be worth the cost involved in learning something new, but if you were to start from scratch and pick one of the two languages, there might be good reasons to pick Rust for the same task.

You can have options and results in C++ if you like (I sometimes use custom result types, and I certainly don't use exceptions), but there's no language-level support for them and that's valuable, I agree. Not sure I understand the second point (I don't have to create uninitialized variables in C++, though I may sometimes want to). As for undefined behavior, I don't personally view that as an issue at all for the most part. I write code for a specific set of compilers running on a specific set of hardware, not an abstract standard. The behavior is what the compiler does (or rather, what I cause it to do) and there's nothing undefined or arbitrary about that.

Anyway, I agree that some aspects of Rust unrelated to memory safety are good for correctness. Unfortunately, I can't pick languages in a vacuum, so I have to weigh that against things like GPGPU support (first rate vs. non-existent), tooling quality (particularly profilers), library support (Eigen alone is worth quite a lot) and other factors. If I could ignore all of those real world issues and just choose the better language, I don't know if I would choose Rust, but it would certainly have a decent shot.

> You can have options and results in C++ if you like (I sometimes use custom result types, and I certainly don't use exceptions)

It's not really practical because C++ has no true sum types. You can emulate them with a Java-style visitor pattern but that carries an immense code overhead.

You have std::variant and std::visit. https://www.bfilipek.com/2018/09/visit-variants.html Or you can use a library: https://github.com/mpark/patterns

> You have std::variant and std::visit. https://www.bfilipek.com/2018/09/visit-variants.html

Which isn't a true sum type because it doesn't nest properly.

> Or you can use a library: https://github.com/mpark/patterns

Interesting; proper pattern-matching is nice, but the lack of type safety is still a major issue.

Maybe I could write a bot for this and then make post about the creation of the bot.

I wonder which of his other strong opinions could have led to a similar result.