I use a hard G when pronouncing gif, and the inventor using a hard G is a good enough reason for me. But the argument that the G stands for graphics being the reason for it is a garbage argument. There are plenty of acronyms that are pronounced differently than the letters that make up those acronyms. For example the U in SCUBA is pronounced as a long U as in rule or June, but stands for underwater, which is pronounced as a short U.
418teapot
joined 2 years ago
Right, but that's why I said it depends who your adversaries are. Really though, think why you care so much about privacy.
Is it because you're doing some shady shit? Probably should do everything in your power to avoid clear text communication every step of the way, including cloudflare.
Or is it (like me) because you are so sick of the corporate surveillance and monetization of your internet activity, and you want to fight back? If that's the case you should absolutely avoid cloudflare like the plague since they literally see all traffic for every website they sit in front of, which these days, anecdotally feels like >50% of the internet.
Ah yes cloudflare: MITM as a service.
It really depends on who your adversaries are that you want to keep private. The coffee shop owner + their ISP + your ISP, or cloudflare. Seeing as cloudflare MITMs an insane amount of the internet these days I'm way more suspicious of them than I am of the alternative. If you're really after privacy I'd recommend self hosting wireguard or something.
Yes, you are correct in that a single individual's action will make no difference, just like your single vote makes no difference either. However if everyone does their part it can make a massive difference.
While your individual contribution makes no difference, you still should try to do your part. Yes, change takes work and a bit of sacrifice. Just like how it takes time out of your day to do research on candidates and go to the polls.
If you don't do the work, it doesn't make you smart or clever, it just makes you an asshole taking advantage of others.
If I super heat a metal and it turns visibly red what is happening? Was it already emitting infrared and as it gets hotter the frequency shifts up? Or is it still emitting infrared but has a wider band of frequencies it is emitting as well (i.e. is it emitting frequencies below infrared as well as visible red)?
The profile in about:profiles is just the default profile and not necessarily the one that instance of Firefox is currently using. For example you can launch a new firefox instance with something like mkdir /tmp/foo && firefox --profile /tmp/foo, but it will still show the firefox default profile in about:profiles for some reason. I believe the current active profile directory can be found under about:support under Profile Directory.
Yeah I've played with git-issue and agree it's not ideal. Have you checked out Sourcehut? It is entirely email based but with some pretty great tooling around it to make it more accessible.
I agree that in a perfect world we have a separate open protocol for all of the non-repository related workflows/data, that has all the features we need. But the nice thing about email is it's decentralized, and everyone already has it. And in my opinion, with the right tooling built around it, it can get pretty close to the same quality of life as a github PR, but also degrade gracefully without it.
I just tried subscribing to [email protected], but it's empty despite the peer tube channel having many videos. Any idea what's going on?
The problem isn't the version control itself. Obviously git continues to function and I can commit things offline in a plane. What I can't do is create/review PRs or read/open issues. That's easy to brush off, but the most egregious thing is the fact that this used to be federated over email!
All we needed was more user-friendly tooling to make it easier for new college grads to start contributing to FLOSS, but instead of better email based tooling we got the centralized trash that github is today.
The problem is all of these apps are using proprietary APIs to communicate to centralized backends, which then deprecate the APIs and the old versions cease to work. Back when software was largely communicating over standardized protocols it was feasible to run an old version of software for years after it had been stopped being maintained, but protocols don't make money, APIs do.
Yeah, sort of. I probably didn't explain super well, and also probably don't fully understand the problem so here are some code snippets that might make things more concrete and you can tell me where my asumptions of your codebase are wrong
So first off we have what I assume you were suggesting with multiple options for the individual db props. I commented where things are painful and bug prone:
If Option is indeed the aproach you want to take we can solve a lot of these
problems by moving all the fields that go optional together into a separate
struct:
We get even more type safety and clarity by making them separate types (and have ArmyWithDbProps wrap Army):
Or we could use Into if it's not appropriate for process_army_from_db to turn an ArmyWithDbProps into an Army:
Also this last example is using clone when if this is in-fact the direction you want to go we could be using pointers to avoid unnecessary clones. Let me know if this is the case and I can write a version with pointers and lifetimes.
I'm sure we've missed something here specific to your software (obviously the above links are all trivial examples), but I just wanted to help clarify my original point with some concrete code. If you can share some of your code we might be able to give you more specific advice.
Relevant XKCD