When is the hashed password needed other than user creation, login or password resets? Once you have verified the user you should not need it at all. If anything storing it on the user at all is likely a bad idea. Really you have two states here - the unauthed user which has their login details, and an authed user which has required info about the user but not their password, hashed or not.
Personally I would construct the user object from the request after doing auth - that way you know that any user object is already authed and it never needs to store the password or hash at all.
I am wary of this. It is very hard to predict what someone else in the future might want to do. I would only go so far as to ensure nothing I am doing will unnecessarily block a refactor later on but I would avoid trying to add or abstract things in ways that make the current code harder to read because you think it might be easier for someone to add to in the future.
I have needed, far too many times, to strip out some unused abstraction to do something that abstraction was never intended to allow because someone was trying to save me time and predict what might happen to the code in the future and got it completely wrong. It is far easier to add an abstraction to simple code later on when it actually helps then to try and figure out what the abstraction is and remove it when it is found to be wrong.
This is abuse of the separation of concerns concepts IMO. You have taken things far too far many made it far less readable overall. The main concern here is password validation - and the code already separated this out from other code. By separating out each check you are just violating another principal - locality of behavior which says related things should be located close to each other. This makes things far easier to read and see what is actually going on without needing to jump through several classes/functions of abstraction.
We need to stop trying to break everything down into the smallest possibly chunks we can. It is fine for a few lines of related code to live in the same function.
Passwords should be hashed, not stored plain text! Hashes are always the same length so this is an immediate sign they are doing horribly insecure things with your password.
So, why wait for windows 10 EOL? If you are already mostly on Linux and are planning on getting rid of the last bits anyway? If you really need to you can always reinstall windows on a second disk or in a VM later on if you really need to - no real need to preemptively do that if you dont plan on using it.
If you have everything you need backed up you can reinstall on a new hard drive and restore everything you need. So you should not be completely fucked. Just an inconvenience you might have to go through. You will lose the stuff not backed up so if any of that is a pain to get again it might be more painful to restore everything.
Others have said some thing you might want to try. But having a spare disk you can swap to is never a bad idea. Disks to fail and you should plan for what to do when they do. Backing up your data is a good first step.
I would say it is not a bad idea to just get a new disk now and go through the process of restoring everything anyway - you can treat it like your disk has failed and do what you would need to do to restore. With the ability to swap back when you need to.
This is a good way to find things you might have missed in your backups.
Why wait? Start using Linux friendly software in your day to day workflows. Then start to dual boot Linux with your current system and start using it more and more. By the time windows 10 reaches EOL you will know if you still need a Windows install or not.
I don't mind ads so much. What I don't want in invasive tracking and collection of every scrap of data they can to push ads on you. Give some dumb ads based on the damned contents of the page and I would be fine. But no, ads is basically a synonym for tracking these days.
Honestly I think function folders is the wrong solution here. I see two different modes of exploring the code here - a high level over view of what is available and a detailed look at the actual code. Code folding to switch between these two modes is not, I think, the best way to do this. Just the easiest thing to replicate in most editors.
A better solution would be a separate view for these - maybe a side bar or overlay that you can popup when you want to navigate the code.
Rust docs has this - a summary of the methods and other symbols on the side with full descriptions in the main view.
Helix has a nice symbol picker which with some tweaks could be a much nicer way to do this:
If it did not strip so much info from the symbols it would basically show the collapsed view along side the code with the ability to search and jump to the code you are interested in. I want to see more refinement on features like this and not just have code folding which I tend to find more annoying and limiting - having to constantly collapse and expand sections when what I really want is to jump around the code base.
Which also has a very disproportionate representation on the web - for obvious reasons. And it is very easy to get stuck in the mentatilty that all you see if the domain you are in so you over estimate how large it is compaired to other domains. But lets not forget general application development, old large scale enterprise, embedded systems, game dev, machine learning and many more spaces where JS/TS are barely used at all.
And given some recent news about Valve working on an ARM emulator and funding Arch Linux to help them start supporting ARM as well they might be working towards that. Though if that is for the deck 2 or something else further in the future is yet to be seen.
The only other major thing for repairability/upgradability would be less glue on the battery and threaded inserts, which doesn’t add size.
The glue was reduced on later versions and especially on the OLED version which also got threaded inserts. So those are already done and I doubt the next version would regress in that regard.
I suspect that concurrency was used back when there were only single threaded cpus, when process scheduling became a thing, to talk about the difference between running one process after another vs interleaving the processes so they appear to be concurrent. Then once true multithreaded programs became a thing they needed a new word to describe things happening at the exact same time instead of only appearing to.
I would argue that rust has a very strong OO feature set (it just lacks inheritance which is the worst OO feature IMO). It is not seen as an OOP language as it also has a very strong functional and procedural feature set as well and does not favor one over the other letting you code in any style that best fits the problem you have.
So I would not say OO and a borrow checker are impossible or even hard. What makes less sense is a GC and the borrow checker. Though there are some use cases for having a GC for a subset of a program.
When is the hashed password needed other than user creation, login or password resets? Once you have verified the user you should not need it at all. If anything storing it on the user at all is likely a bad idea. Really you have two states here - the unauthed user which has their login details, and an authed user which has required info about the user but not their password, hashed or not.
Personally I would construct the user object from the request after doing auth - that way you know that any user object is already authed and it never needs to store the password or hash at all.