Even in that scenario, having the duress pin option does not make things worse. It's functionally equivalent to smashing the phone, just easier to do with one hand.

i.e. whatever they do to you if you wiped the phone via duress PIN, they would already do to you if you managed to smash the phone.

> Other Email providers such as Tuta which also offer encrypted emails, were forced to install a backdoor. As soon as the police arrive, every future email sent to the account in question is copied unencrypted without the person being informed.

Important caveat: Tuta was required by a court to provide police with access to a customer's _unencrypted_ emails (ie regular SMTP mail). The police had also asked for a backdoor to Tuta's E2E emails, and that request was rejected by the courts.

But the idea behind Tuta and Proton is that emails are encrypted when they arrive in the inbox. The fact that emails sent between Tuta users are still safe offer little added value because distribution is far too limited. The reason people choose such a provider is that they do not want the authorities to have access to their mailbox, but this is undermined by a backdoor. Switzerland is much better off in terms of the legal situation in this area.

The enforcement isn't the issue, it's the scarcity.

Often it's to acquire the founders' knowledge and/or IP.

But Gastown is MIT licensed, and Yegge is bragging about never having looked at the code at all.

> I always wonder why people bother with providing source under a source available license. [..] There's little to no benefit to outside users. Any work they do on the code is effectively free work they do for you that entitles them to nothing.

Don't need to make PRs to benefit from the source being available. Running software whose source code has been under public eyeballs, and that I have compiled myself (or that a trusted third-party has compiled) is far more secure than running a binary blob that may or may not do what the developer's marketing page promises.

> If something like Bun (recently acquired by anthropic) becomes orphaned, we'd still have the git source code and a permissive license.

Closed-source apps have had source-code escrow clauses for a long time, exactly to avoid that problem. "If my company shuts down, you get all the source code and can do whatever you want with it."

Such clauses can, and should, be brought over to source-available licenses, where they would also be trivial since you don't even need a physical escrow.

> same crime as sellers of 'light' products which replace nutritious ingredients with water or air

The analogy, in this case, would be replacing NON-nutritious ingredients with water or air.

There's nothing any UniversalBlue image tweaks that you couldn't tweak yourself. It's just adding/removing packages, adding/removing drivers, a few configuration scripts, and a bunch of tweaks to fix well-known gaming-related issues.

But the point is that, if you want to game on Linux, you probably want to perform exactly or almost exactly the same tweaks that Bazzite already does. So why bother doing them yourself?

It's not even a linux-from-scratch situation where you'd do it for the sake of learning. Googling "my controller doesn't work right", finding some discussion threads, and copy-pasting a bunch of fixes isn't particularly interesting.

I want to bear witness that I did exactly that when I downmoted one of my computers from 'gaming machine' to 'closet server'.

One `rpm-ostree rebase` from Bazzite to a server-oriented flavour of Fedora Silverblue and it's been running and updating flawlessly since then.

Layman question: say you have a C codebase with a bunch of preprocessor macros and you want to get rid of a particular one that's too clever, and assume no other macros depend on it.

Is it possible to command the preprocessor to take the source files as input and print them out with that one particular macro expanded and no other changes?

Intuitively, it sounds like it should be possible, and then you'd end up with a code base with a bunch of repetition but one fewer too-clever abstraction - and refactoring to deal with repetition (if necessary!) is a far more approachable and well-understood problem.

(Kind of like how some fancy compiles-to-javascript languages have a literal 'mytool --escape' command that will turn the entire code base into a plain, non-minified javascript in case you ever want to stop using them.)

That's a great question.

I found this on SO:

https://stackoverflow.com/questions/59553295/selective-macro...

Maybe that would work for your use case?

What I like about your question is that I always assumed the answer was a hard 'no' but that appears not to be the case.

It was a theoretical question. It's not the first time I hear the complaint '$previous_dev left a bunch of unmaintainable macro tricks in a C codebase' and I thought, since those macros get expanded as part of the compilation process, surely it should be possible to intercept and capture the expanded version?

Even if a whitelist is not available (the SO question involves a particular C++ preprocessor and may not apply to others), a hacky approach might be to comment out all the #defines in the codebase, uncomment the ones you want to get rid of, and then run the full preprocessor task on it. Ugly but probably doable for a one-time refactoring.

One quick improvement would be to style the number boxes to include decimal separators. For a few answers I was squinting to check if I had typed six or seven zeroes, for example.