bjorney

OP said it was to notify you when an alarm went off, not when it ran out of batteries.

You seem content to entirely gloss over the issue, which isn’t the pros/cons of a particular writing style, it’s that the maintainer could have said ANY of the things you said, but he didn’t

If I was the maintainer, I too would probably reject the PR because it didn’t remove the gender entirely.

Cool, but that isn’t what happened here. The PR was closed immediately because the maintainer considered using gender neutral pronouns “personal politics” - he had ample opportunity to clarify his stance, or simply comment ‘resubmit in passive voice’, but he didn’t. Clearly the problem wasn’t the active voice, it was the summary of the change, because when that exact same PR was re-submitted much later with a commit message of ‘Fix some minor ESL grammar issues’, it was accepted with no discussion

As an aside, I absolutely disagree with the use of passive voice. It’s more verbose, and harder for the reader to comprehend. It’s why every style guide (APA, Chicago, IEEE, etc) recommends sticking to active voice, especially in the context of ‘doing things’.

If goes against established norms here

What’s the established norm here. All people compiling software by source are male?

he said politically motivated changes aren’t welcome

What’s politically motivated about changing “he” to “they”. As you said, gender doesn’t apply here, so the neutral word is literally preferable.

Yes, I’m sure that PR would have been accepted instead /s

But you’re right, it doesn’t matter at all, the reasonable thing to do would have been for the guy to spend 3 seconds clicking the accept and merge button, or 6 seconds making your change. instead he wrote a comment stating that inclusive language has no place in his project

https://github.com/SerenityOS/serenity/pull/6814#issuecomment-830793992

Really?

This screams “women not wanted” to me

it’s literally easier to do on a technical level

I wouldn’t go that far. It’s still trivially easy, and arguably best practice, but it’s certainly more complicated than issuing an in-place update

If the code doesn’t change, the resulting docker image will have the same hash, and a new image won’t be created

https://github.com/jackett/jackett/releases

Jackett is literally just releasing a new version every day

and I’ve encountered zero bugs so far

This is my only complaint - it crashes a lot for me

The content of the email is very laissez-faire, e.g. "we legally have to send these ¯\_(ツ)_/¯ "

I collect these like pokemon 🙃

Especially because it’s to a newbie, who stands to benefit the most from using an OS with more user share and more available online resources.

The local Loblaws near me (the Canadian devil chain) set theirs up with like a 5% weight tolerance, so if you put something down too fast? Sensors go off. Bag it then put it on the scale? Sensors go off. Manufacturer put too many chips in your package? Sensors go off.

I don’t shop there anymore

The other commenter cropped their image right before the last massive drop in 2015

AFAIK if you spend at least 2 years studying here you automatically qualify for a 3 year work permit. I think rolling that into permanent residency is a lot easier than just applying for a work visa or PR out of the gate

International student tuition is way more expensive here in Canada than it is for citizens, but I’m not sure how it stacks up against normal US tuition.

Grain of salt, everything I’ve said is based on anecdotes from people I know who went through it

It’s really not that complicated. At a high level:

• $5/mo for having the service turned on
• $5/mo for every TB storage above and beyond the first 1TB
• $1 for every TB of data transfer beyond the first 1TB in a month

And then divide those numbers because it’s actually billed by the hour

That assumes that an adversary has control of the browser

No it doesn’t, if they intercept an encrypted password over HTTPS they can resend the request from their own browser to get access to your account

The big reason you don’t want to send passwords over https is that some organizations have custom certs setup

What is the problem with that? The password is secure and only shared between you and the site you are intending to communicate with. Even if you sent an encrypted password, they wrote the client side code used to generate it, so they can revert it back to its plaintext state server side anyways

It is better to just not send the password at all.

How would you verify it then?

If not sending plaintext passwords was best practice then why do no sites follow this? You are literally posting to a site (Lemmy) that sends plaintext passwords in its request bodies to log-in

Client side verification is just security by obscurity, which gains you very little.

If someone is capable of MITM attacking a user and fetching a password mid-transit to the server over HTTPS, they are surely capable of popping open devtools and reverse engineering your cryptographic code to either a) uncover the original password, or b) just using the encrypted credentials directly to authenticate with your server without ever having known the password in the first place

The word ‘decipher’ is doing a lot of heavy lifting. I’m wondering if they socially engineered or just found it written somewhere in the house?

You can plausibly brute force up to 4, maybe 5 words of a seed phrase. It takes longer than a normal password because every seed phrase is technically valid, so the only way to know if your brute force is successful is to generate thousands of addresses at each of the different derivation paths you may expect funds to exist at.

The same seed phrase is used for Bitcoin, Ethereum, Monero, etc, but each currency uses the seed phrase to generate addresses in a slightly different standard. Additionally, each wallet uses a slightly different variation of that. Within each wallet is a notion of accounts, and within each account you could have dozens of addresses. You need to generate each of those addresses, and scan each cryptocurrencies blockchain to see if those addresses have ever been used.

Realistically one of three things happened: his seed phrase was written down and they found it, it was password protected or on a drive with weak AES encryption and they cracked THAT instead, or finally, he used a hardware wallet and they exploited a firmware vulnerability to lift the PIN and transfer out funds and/or read the seed from the device

You are acting like someone checked off a “log passwords” box, as if that’s a thing that even exists

Someone configured a logger to write HTTP bodies and headers, not realizing they needed to build a custom handler to iterate through every body and header anonymizing any fields that may plausibly contain sensitive information. It’s something that literally every dev has done at some point before they knew better.