I would say that myself and most programmers appreciate there is always some logical root cause for why things work or don't, and its very unsatisfying to have thigs work without knowing why. It's also problematic, because if you don't know why then it might break again in future and you can't fix it.
That said, programming is different from pure science. The explicit point of science is to uncover the truth and understand and make it replicable. The point of programming is to have a software product that functions.
So realistically we may as programmers occasionally let something slide without knowing the full detail, because we are working to different goals.
This is especially true based on the category/criticality.
Something "magically" starts working in the core backend payments API code? Not good enough, we need to know exactly what the cause was and cover it in tests.
Something "magically" fixes the UI bug that caused a weird but inconsequential margin padding that affected Samsung Galaxy S21 devices ONLY and no other phone? Hallelujah, it's a miracle.
OP specifically said they don't want to dual boot, and I honestly understand why they would say that.
When you dual boot you need to worry about what bootloader is in use and how it is set up. You might find yourself in a situation where you later decide to move fully to Linux and use the old Windows drive as storage but you can't because if you wipe it then everything stops working.
Windows has even been known to destroy dual boot setups occasionally during Windows updates.
All very solveable if you have the right knowledge, but if you want to keep your life simple then swapping hardware has guaranteed safety (nothing can go wrong with the contents if a drive if it's not plugged in, after all) and it's very predictable and understandable.
Right, so the hashing and comparison of hashes also can happen in the back end, and the API response can just be true/false whether it's a match or not. That way the hashes and the hashing algorithm could all stay private.
The comparison API would of course also need its own rate limits and backoff etc to ensure it cannot be used to bruteforce attempts until you get a 'true' back.
All in all it's a terrible idea though and nobody should actually do this.
Personally I feel what it gave them - primarily - was the ability to be independent of Microsoft, not beholden to them in any way whatsoever, and not having to pay them any license fees.
The fact that after putting so much work into making Proton and that whole toolchain amazing it actually turned out faster than Windows, well, that's juat the delicious icing on the cake, from a commercial perspective.
Following on your theme of charitably assuming at least the possibility of a safe implementation, this could certainly be done without surfacing the hash on the front end.
It could be that each keystroke triggers an API request which sends the current input, then the API hashes it and compares that to the original, entirely in the backend.
"The squeaky wheel gets the grease" is an adage that is unfortunately true, and I find it absolutely infuriating.
I would much prefer that we can all be polite and courteous to each other, so when being polite fails but having a screaming tantrum gets results it really makes me annoyed at the unfairness.
Spend it on completely mundane and practical things like securing a place to live, and buying a suit to interview for a job - because 5k simply isn't enough to make any immediate life-changing money on, even if you're from the future.
And I really need a place to sleep.
5k might be quick money if I was a sports buff and could remember match results, or knew the exact dates of significant events, or remembered a bunch of old lottery numbers, but that's not the case so it's off the table.
So yeah. Get a place. Get a suit (it's 1990, you need a suit), Get a job, earn some money, and spend half my wage on shares in Microsoft and other companies I remember as doing well.
I wouldn't be surprised if they use it for creation in some cases, depending on locale, or if you seem "suspicious" to their metrics in some way, e.g. registering while on a VPN
In one part, two characters are speaking over "radio" comms using code talk - presumably in case there are any Empire operatives listening in. And prior to that they kept missing each other because they weren't at their radios at the same time. Derp!
So you've got hyperspace travel and laser guns, but no data encryption, or text messaging. Alright then.
Except of course, they do have those things when the plot calls for it, and that's another reason to consider it fantasy. In most sci-fi the rules stay pretty consistent, but in fantasy it's flexible.
I guess some of us just like to think the search bar and the address bar are conceptually different interface elements with different reasons to exist.
Just for clarity, Graphene doesn't provide a "neutered" version of play services - the version of play services which runs is the same code as provided by Google, with the only difference being that it runs in a sandbox which only grants it the same level of permission as normal apps (which you can choose to grant or not) rather than running as effectively root on your device like it does on most android phones.
I love how the top two points, "Choose how you search, right from the address bar" and "Keep your original search visible" are things that we always had by default in the old days with the separate search bar, until Firefox blindly copied Chrome and went to the unified bar.
And now it's back as if it's some kind of revolutionary feature, rather than they made it worse and now they're making it better again.
Not that I ever stopped using the separate search field, I always turn that on.
No, generally speaking. But sometimes yes.
I would say that myself and most programmers appreciate there is always some logical root cause for why things work or don't, and its very unsatisfying to have thigs work without knowing why. It's also problematic, because if you don't know why then it might break again in future and you can't fix it.
That said, programming is different from pure science. The explicit point of science is to uncover the truth and understand and make it replicable. The point of programming is to have a software product that functions.
So realistically we may as programmers occasionally let something slide without knowing the full detail, because we are working to different goals.
This is especially true based on the category/criticality.
Something "magically" starts working in the core backend payments API code? Not good enough, we need to know exactly what the cause was and cover it in tests.
Something "magically" fixes the UI bug that caused a weird but inconsequential margin padding that affected Samsung Galaxy S21 devices ONLY and no other phone? Hallelujah, it's a miracle.