If your "community event" has such a high carbon cost of needlessly burning fossil fuels and destroying tires, not to mention the noise pollution and safety aspects, maybe it's time to find a new community event.
Why not a street take over of bicycles? How about meeting up at a third space like a park, bar or cafe? What about collectively doing some tactical urbanism to improve your community - paint some crosswalks, add bollards to force pedestrianization.
On my machine at least man openssl shows that -k is for specifying the password you want to derive the key from, so in that case I think you are literally using the string /etc/ssl/private/etcBackup.key as the password. I think the flag you want is -kfile.
You can verify this by running the command in strace and seeing that there is no openat call for the file passed to -k.
Edit: metiulekm@sh.itjust.works beat me to it while I was writing out my answer :)
Since I like to use bemenu I just wrote the derivation myself, it's super short and simple especially borrowing from the build.sh script in wofi-emoji repository. You can get the emoji data like so:
emoji-data = pkgs.runCommand "emoji-data" {
buildInputs = [ pkgs.cacert pkgs.curl pkgs.jq ];
outputHashAlgo = "sha256";
outputHash = "sha256-znAwFu0vq2B7lQ8uvG0xKv9j3jYr6P0CZpjoKMNPhZw=";
} ''
curl 'https://raw.githubusercontent.com/muan/emojilib/v3.0.6/dist/emoji-en-US.json' \
| jq --raw-output '. | to_entries | .[] | .key + " " + (.value | join(" ") | sub("_"; " "; "g"))' \
> $out
'';
And then write a small wrapper script of your liking. I'm using wtype and bemenu, but you could just as easily use wl-clipboard and rofi for instance. This is to me one of the huge benifits of nix, how you can slam these small scripts together and not worry about missing dependencies when taking the configuration to other systems.
I hate that Google is exerting even more control on the internet with their TLD, but I don't really think this attack is made all that much worse with .zip TLD. I can already bury a .com in a long URL and end it in .zip just fine like so:
https://github.com∕foo∕bar∕baz@example.com/foo/bar/baz.zip
Or even use a subdomain to remove the @:
https://github.com∕foo∕bar∕baz.example.com/foo/bar/baz.zip
The truth is most people don't look much at URLs outside of a domain to verify its authenticity, at which point the .zip TLD does not do much more harm than existing domains do.
For mitigation, Firefox already doesn't display the username portion of the URL on hover of a link and URL-encodes it if copy-pasted into the url bar. It also displays the punycode representation when hovering or navigating to the second example.
Edit: looks like lemmy now replaces 0x2215 which is a character that looks like forward slash with an actual forward slash, so my comment is a bit more confusing. For clarity, the slashes before example.com in the above urls were 0x2215 and not "/".
While I agree that first party systems suck, as someone with neither an iOS or Android device I personally prefer something work rather than a screen that says "connect iOS/Android".
Definitely agree, but your link is protected by cloudflare (yet another centralized service destroying the internet) and therefore I'm unable to get through because I have privacy.resistFingerprinting enabled on my browser so cloudflare is unable to determine I'm human I suppose.
I despire youtube and it's monopoly, and I think it get's an appropriate amount of hate on here and HN, but what confuses me to no end are the people who complain about youtube turn right around and constantly recommend cloudflare. Can someone explain what I am missing?
That's wild, I've never seen an upside down port.
I agree reversibility is better and am happy usb c will finally kill this meme.
Yeah that's fair. But I feel like I've seen these "USB superposition" memes since before IoT was even a thing.
Can someone explain to me why I keep reading about people having problems plugging in USB A connectors upside down? I feel like I'm taking crazy pills. Per the spec, the holes always go up. They indicate the correct way to plug in the port. Not only that, but the printed logo on the connector also always goes up.
The only time this is SLIGHTLY confusing is if you have a desktop tower where the motherboard is essentially mounted sideways, but for that case it just takes an extra second to think which way is "up" from the perspective of the motherboard.
And before anyone says "who reads the spec?", it feels like I subconsciously knew this for something like a decade before I even knew what a spec was.
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.
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.
It is likely not worth your effort as whatever you come up with will likely result in discord deactivating your account for breaking their ToS, or them breaking their API forcing you to constantly play catch-up.
This is why open communication protocols are so important. Email is still as ubiquitous as it is because it's a protocol, not an API.
I personally think it would be less overall effort to get your friends to switch to an open protocol like matrix, or XMPP than it would playing cat and mouse with proprietary APIs. But you do you, I wish you the best of luck!